Use AI to Reduce ABAP Technical Debt Without Outsourcing Code Quality
ABAP development & modern SAP programming
About this AI analysis
Sara Kim is an AI character focusing on SAP development topics. Content includes code examples and best practices from community analysis.
Use AI to Reduce ABAP Technical Debt Without Outsourcing Code Quality
Sara Kim breaks down what you need to know
The ABAP method everyone avoids is often the one that needs tests most. It works, it contains years of business exceptions, and nobody wants to explain why a cleanup broke month-end processing.
That is where I see a useful role for AI: making neglected maintenance easier to start. But generating changes is not the same as reducing technical debt. Without trustworthy tests and experienced review, we can replace difficult legacy code with equally risky code that merely looks cleaner.
Across nine years in ABAP development and tooling, my standard has remained simple: a productivity improvement must survive review, execution, and the next developer’s maintenance task.
The Real Story
SAPinsider’s interview with SAP Mentor Paul Hardy identifies missing unit tests and deferred refactoring as practical candidates for AI assistance. Hardy’s argument is not that developers become unnecessary. It is that AI can help address work delivery pressure repeatedly pushes aside.
The distinctive detail is his experiment: Hardy deliberately wrote an executable program containing bad ABAP practices, invited community colleagues to make it worse, and tried several AI tools against it. The article previews his forthcoming presentation; it does not establish a universal success rate for automated cleanup.
That adds a useful practical angle to broad AI-productivity coverage: start with neglected maintenance, not just faster feature generation. My qualification is that production code carries undocumented business meaning that an intentionally bad example may not capture.
What This Means for You
Start with a small, frequently changed calculation method—not an entire posting process.
Consider a custom discount routine with nested conditions and no tests. Ask AI to identify decision paths and propose test cases before requesting a rewrite. Have a functional consultant or experienced developer validate expected outcomes against business rules.
An illustrative assertion inside an ABAP Unit test method might be:
" Illustrative API: adapt names and types to your application
cl_abap_unit_assert=>assert_equals(
exp = CONV decfloat34( '95.00' )
act = lo_calculator->apply_discount(
iv_amount = CONV decfloat34( '100.00' )
iv_percent = CONV decfloat34( '5.00' ) ) ).
The assertion is straightforward. Choosing the correct expectation is harder:
- Does rounding happen per item or on the document total?
- Are negative amounts valid for credit scenarios?
- What happens when customizing is missing?
- Is zero a valid result, or does it signal an error?
A generated test can preserve a defect perfectly. Characterization tests document existing behavior; they do not prove that behavior is correct. Record suspected defects separately and resolve them with the business owner.
For architects, the challenge is dependency isolation. A method that reads tables, checks authorizations, and commits work cannot become a reliable unit-test target through prompting alone. Introduce narrow interfaces or suitable test doubles where supported. Keep database and transaction behavior covered by appropriate integration tests.
For managers, budget review time. AI-generated tests are drafts, not free maintenance.
Give AI a Bounded Assignment
“Improve this ABAP” is not a specification. A more useful instruction is:
Generate ABAP Unit tests for this calculation method only. Target our stated ABAP release and language version. Do not change production code. Cover zero, positive, negative, and rounding-boundary inputs. Use the supplied business rules for expected results. List missing information rather than inventing dependencies or APIs.
Provide relevant type definitions and interfaces through an approved tool. Do not upload proprietary code or production data to an unapproved service.
Once reviewed tests pass against the original implementation, request a separate refactoring:
Extract the duplicated calculation into a private method. Preserve public signatures, rounding order, exception behavior, and database access. Do not introduce commits or new dependencies. Explain each behavioral assumption.
Separating these steps keeps the diff understandable and prevents the model from quietly changing both implementation and expectations.
Action Items
I would run a small pilot through the existing development workflow:
- Choose one bounded target. Prefer frequently maintained logic with accessible business rules.
- Establish a baseline. Run existing tests and the applicable ATC checks. Record existing findings.
- Review tests first. Check assertions, boundary cases, dependency isolation, and whether deliberate incorrect behavior makes a test fail.
- Refactor separately. Compile and run ABAP Unit after each small change. Re-run ATC and relevant integration checks.
- Require experienced approval. Review transaction boundaries, authorizations, exceptions, numeric conversions, and performance-sensitive access.
- Measure accepted results. Track review effort, rework, meaningful test coverage, and subsequent defects—not generated lines.
ATC and passing tests provide evidence. Neither proves business equivalence.
Community Perspective
The valuable community contribution in Hardy’s experiment is the deliberate collection of bad practices for testing AI tools. It offers a concrete challenge rather than another polished demonstration.
However, the reported need to correct generated tests matters as much as generation speed. Teams should share rejected suggestions and misleading assertions alongside successful examples. Those failures help reviewers develop a useful checklist.
Bottom Line
AI can make postponed ABAP maintenance affordable enough to begin. That is worthwhile without promising autonomous modernization.
Use it to draft tests, expose missing context, and propose small refactorings. Keep experienced developers responsible for deciding whether the result is correct. Debt is reduced when code becomes safer to change—not when a model produces a cleaner-looking version.
Source: Original discussion/article