Why Battle-Tested Software Engineering Still Matters in the Age of AI

Software Excellence Alliance

While use of AI in developing and maintaining software is increasing globally, this use is relatively new, and proven practices for using AI effectively are still emerging. There are different ways to use AI, but their effectiveness varies with use cases, lifecycle phases, and practice variations. Activities like prototyping can move incredibly quickly, but product quality does not come for free and sharp increases in technical debt can result if software engineers do not use AI responsibly.

Software engineering principles and practices can provide significant value in guiding the use of AI in development. This talk shares observations and lessons from both personal use of AI and study of its application across multiple projects. The talk will explore different modes of AI usage from code assistants to agentic workflows, and the gap between “vibe coding” and disciplined software engineering. Finally, it will examine how AI is changing the development equation by increasing pressure as code is produced in larger volumes and at a faster pace than teams can validate and integrate incrementally.

https://softwareexcellencealliance.org/why-battle-tested-software-engineering-still-matters-in-the-age-of-ai/

Tim Haston

I thought the talk was excellent. It touched on all the key issues. My experience has been that it tends to go greenfield when adding new functionality, not knowing that a preferred technology has already been chosen elsewhere. Also, it is not that great at refactoring, even its own code!

By the way, I am looking for a new position between now and the end of the year. If any of you know of Software Engineer positions out there, I would appreciate any help so much!

Thanks,

-Tim

Julia Mullaney

I absolutely love the way you characterized AI as a young engineer who doesn't even know what they don't know. I'm using AI and it's doing great, and then all of a sudden I think, where did this come from? What do you think the impact will be for young engineers learning on the job? If both the engineer and the AI don't know what they don't know, how will that change how we educate young engineers?

Presenter

Julia Mullaney AI is obviously changing how we code. I used to spend a lot of time figuring out a framework, a language, or a technology; but perhaps that's the easy part. The hard part is understanding the business. If you're in train control, for example, understanding all of those train control rules and why people design train control systems the way they do is what really matters. So if I were a young person starting out today, my focus wouldn't be on the technology itself the way it might have been when I got started. It would be on becoming a train control expert. Yes, I'm going to use AI, and I need to understand how it works. But at the end of the day, if I understand the business side, the mission side, then I can tell when the AI is making a mistake. I know it may not be the answer everyone wants to hear, but AI is taking away the easy, repetitive tasks. If I want to still be employed in ten years, I need to add value, and that value is in systems engineering and higher-level thinking.

Larry Maccherone

Referring to slide 11 and the discussion about hidden requirements, with the large dependency diagram and the risk of breaking dependencies unintentionally. Isn't AI better at crawling through a code base to find those hidden business rules and dealing with large numbers of dependencies?

Presenter

Larry Maccherone AI is definitely good at crawling through a code base and can identify some of the dependencies. As for business rules, it may pick some up, but it won't catch everything. We're working with customers who are modernizing legacy COBOL code that was written before I was even around. There are a lot of hidden assumptions baked into how people use and interact with the system, and AI won't necessarily find all of them. If you're doing a modernization effort on a code base like that, you may absolutely miss some. That's why you still need additional effort on the validation side to make sure nothing critical is overlooked.

Here's a concrete example: when I was in industry, we were refactoring our code base and found a flag used throughout a particular module that nobody could explain. It took us two full weeks to reason through why that flag existed, and we eventually concluded we didn't need it; and that was with our own code, code we had written ourselves. When you start digging into code someone else wrote, it gets considerably more complicated. So while AI is very good at crawling through large code bases, there is still a real possibility of missing things.

That said, I think it can work both ways: humans can try to identify hidden rules, and then AI can help find what they might have missed, or vice versa.

Attendee

Code generation is accelerating, but validation doesn't scale at the same rate. What trends are you seeing in generative AI helping to scale the validation side of the equation?

Presenter

Attendee That's a very good question, and honestly I don't think the problem is solved. We do see people trying to use agents to perform reviews and to validate code against requirements. Another trend is using one model - say, from OpenAI - to produce the code, and a different model from a different vendor to do the validation. I suspect more efforts will move in that direction.

Whether we'll ever reach 100% AI with no human in the loop, I'm not sure. A lot of that depends on your risk tolerance. It's one thing if you're building a phone game where a malfunction just means you can't play. It's quite another if you're building a medical device. What that validation effort looks like will ultimately depend on your business model and the type of application you're building.

Jeff Schwalb

AI capabilities are evolving so quickly. How can I get the people in my organization to understand how important this is, and how fast everything is going to change?

Presenter

Jeff Schwalb That's really more of an organizational question than anything else. The organization that wants to use these tools has to get behind them. In my experience, there needs to be a champion within the organization: someone who will show others how to use these tools to get real benefit. If you just throw tools at people with no guidance, they'll either misuse them or actively resist using them at all. You need someone who can say, "Here's how I'm generating code now, and here's how we're doing validation to make sure it still meets the quality we need…and by the way, we're going faster because of this." You have to show people the value. If they don't see it, they won't adopt it.

Attendee

Michael Cosentino: I've been in various stages of software development for a while. One of the best tools I saw was Rational Rose, at least for C++; and it seems like it would pair very well with AI today. It could generate diagrams and charts from code, or vice versa, and drill down to whatever level of detail you need. It could bring together legacy code bases that had diverged, and help you make sense of things and clean them up. The product got expensive and eventually disappeared into other products, and I haven't seen anything like it since; but it seems like it would be the right tool to match up with AI. You could have AI generate the diagrams and charts, or designers could design in the tool and let AI interpret it.

Presenter

Attendee We shouldn't see AI as the end-all be-all; it's yet another tool. The real question is: what other tools can we pair it with to reach our business goals? Whether that's a knowledge graph for code analysis, static analyzers feeding into the loop, or something else, it's going to be a combination. It won't be just one tool, and it will probably vary depending on the organization.

Larry Maccherone

Attendee I think you're onto something, and it aligns well with what Mario has been saying. Some of the best intent-communication cycles I've had in my systematic agentic engineering process have involved sequence diagrams in particular. Mermaid is a technology that lets you specify sequence diagrams in text, and AI is really good at manipulating text. So imagine describing what you want in high-level human terms and asking for a sequence diagram that captures part of it. Then you push back: "The sequence diagram is wrong: doesn't it need to account for this failure mode? What if there's a network disconnection here?" By the end of that session, you have a brilliantly refined, crystal-clear description of what the system should look like and how it should behave. I'm using sequence diagrams more now than I have since Rational Rose died.

Attendee

Attendee James Ivers: This brings back memories…Software Through Pictures, Rational Rose. There's always been a challenge with modeling languages around how well they fit what you're actually trying to model. UML has been an awkward fit for a lot of architectural solutions; it fits well for object-oriented design but has struggled elsewhere. AADL is a good example of a domain-specific language aimed at safety-critical systems. It has the right vocabulary and concepts for that kind of work, and that specificity has been a real point of leverage.

There is work at the SEI right now connecting AADL with SysML v2, which moves us toward a more well-sustained tool base using languages people are more familiar with. There is also work on using generative AI to generate SysML models from textual descriptions.

But this isn't magic; there are significant gaps. It's relatively easy, with some MCP servers and integration work, to get AI to produce syntactically well-formed SysML descriptions. But that doesn't mean those models are semantically capturing your intent, or that the intent you're describing actually matches what's in the code. Those abstraction gaps are still hard to close. Generating architectural models from existing source code has been a thorny problem for thirty years, and AI is a new tool that helps with some aspects of it more quickly; but it remains highly interactive.

We've been working with an Army system where we, as engineers, had to first understand the key architectural concepts like shared memory, sockets, and how they're used differently in that particular system. Once we had that understanding, we were able to write scripts that quickly distilled the relevant information. Now we have the beginnings of a knowledge graph that brings different sources of information together and gives us a more reliable, higher-level understanding than AI alone could provide from textual descriptions.

One more caution on legacy code and AI: be wary of names. Older systems - legacy COBOL, for example - often have obfuscated variable and function names. A program with meaningful names gives AI far more to work with than one with cryptic identifiers, because inferring semantics from names is a significant part of what a language model does. Keep that in mind when evaluating the results, and use them with care.