“You Can’t Take Away a Job That’s Not Being Done”: SAP Mentor Paul Hardy on Using AI to Clean Up Bad ABAP

Paul Hardy, an ABAP developer at Heidelberg Materials and an SAP Mentor, set out to write “the worst possible ABAP program in the world” that would still run. He says he did “everything that I’ve been trying to avoid for the last 25 years.” He then asked colleagues in the SAP community to help him make it worse before running it past several AI tools.

Hardy will present the results on November 19 at Mastering SAP Collaborate in Sydney, in a session titled “Can AI Rescue Your Worst ABAP?” The author of ABAP to the Future and SAP Press E-Bites on refactoring legacy code, he will use the program as one of several cases.

Ahead of the session, Hardy told SAPinsider that AI can take on the cleanup work developers often skip, the same neglected work that turns custom code into technical debt. Developers still have to judge what AI produces and tell it precisely what they need.

Why Legacy ABAP Builds Up Technical Debt

Hardy’s experiments start from a simple problem: once code works, developers rarely get time to go back and improve it.

Projects and day-to-day work keep pushing them to the next task. “As soon as you’ve got something working, you’re basically forced to move on to the next thing,” he says. “And that means everything ends up suboptimal.”

He has been there himself. Recently, he left a comment in his own code promising to split it into smaller modules once it worked, then added another: “I bet I won’t have the time.”

In his account, two kinds of work fall away first: refactoring and automated unit tests. Refactoring makes code easier to maintain without changing what it does. But Hardy says management would consider it a waste of time if they knew developers were doing it.

Unit tests present a similar problem. He estimates they double development time and says management would therefore tell developers not to write them. His argument that the work pays off in the long run is difficult to make, he says, in an era of “quarterly bonuses and quarterly results.”

Over years, that skipped work produces the problem his session description starts from: custom code that works but that nobody wants to touch, where thin documentation and legacy design make even simple changes risky and slow.

Where AI Can Help Clear the Backlog

Hardy sees that skipped work as the obvious place for AI. Asked for unit tests covering a whole program, an AI tool can propose a full set in seconds.

The output needs correcting. Hardy has found the generated tests contain syntax errors, but they are “not too difficult to fix up.” He puts the extra effort at about an hour, compared with doubling development time when the tests are written by hand, and sees the same logic applying to refactoring.

That changes the trade-off teams and managers face. If AI handles the work, Hardy says, “it doesn’t impact the development time,” or the team’s speed and agility, so it no longer has to compete with project deadlines.

He calls the next point the most important one he wants developers to hear. “You can’t take away a job that’s not being done,” he says. “It’s impossible.”

Hardy draws a sharp line between that use of AI and the way it is often sold. Vendors, he says, present AI as a silver bullet that lets companies do without most of their programmers. “Nothing could be further from the truth.” In his view, AI takes on the work, but developers stay responsible for the code.

What Developers Still Have to Decide

Staying responsible starts with understanding what AI produces. “If I can’t understand the code it’s generated, how do I know it’s right?” Hardy says. Nothing should get through, in his view, until it has been “analyzed to death by a human,” even when AI wrote all of it.

His deliberately bad test program shows why that review matters. The tools didn’t all read it the same way. Some handled it well, and one recognized what it was looking at: “I suspect this is deliberately badly written.” Others missed that the code was a setup. A developer has to be able to tell when a tool has it right and when it doesn’t.

Hardy’s session also carries a second message: people are approaching AI “the exact wrong way round.” His example is vibe coding, where a user describes what they want in plain English and lets the AI work out how to build it. Hardy says his experiments showed that is “a sort of backwards way to do it.” In his view, the person should write the specification and let the AI work from it.

“The art of this is to be able to write a good specification document,” he says, one an AI can understand. He often repeats a line he read online: “The new programming language these days is English.”

That puts the burden on whoever gives the instructions. Hardy says a slightly wrong question can produce nonsense, and asking the same question three different ways usually gets an accurate answer. “It’s no different really than programming,” he says. “You give it the wrong instructions, it’ll come up with something plausible but incorrect.” His own prompts can run for pages, which he says is sometimes best.

What This Means for SAPinsiders

Treat neglected work as AI’s first job. Use AI to take on the cleanup work projects push aside, such as testing and improving older custom code. Organizations can start reducing technical debt without slowing current projects.

Plan for developer review from the start. Make review part of how AI is introduced, with developers who understand the code checking what it produces before it goes into use. Teams keep the speed AI offers without losing confidence in what goes live.

Treat specification writing as a core skill. Have developers write detailed specifications before AI generates anything, and expect to refine instructions when results miss. Teams get more reliable output and spend less time fixing code that looks right but isn’t.