Checking AI-Generated ABAP Before You Run It
LLMs are noticeably worse at ABAP than at Python or JavaScript, and the reason is boring: there is far less ABAP on the public internet to have learned from. The output usually looks right. The failure mode is not gibberish — it is plausible code with a fabricated class name in the middle of it, or a type that behaves differently than the model assumes.
Pasting that into a client system to find out is an expensive way to check. This page is about the cheap way.
Opens the validator with ABAP that parses, runs, and is still wrong twice.
What actually gets checked
Four stages, in order. Each one can only run if the one before it passed, which is itself informative — code that never reaches "Transpile" did not fail at runtime, it failed to be ABAP.
-
1. Syntax
Does it parse at all? This is where invented statements and unbalanced blocks surface.
-
2. Lint and LLM pitfalls
163 abaplint rules, plus four rules written specifically for the mistakes models make.
-
3. Transpile
ABAP to JavaScript. Constructs that parse but cannot be executed here show up at this step.
-
4. Runtime
It runs. A dump here is a real defect, not a limitation of the checker.
The four patterns a linter alone will not tell you about
A standard linter checks ABAP against ABAP conventions. These check it against the specific ways a language model goes wrong — mostly by importing habits from languages it knows better.
Class names that do not exist
CL_ABAP_STRING_UTILITIES sounds real. It isn't. Models produce plausible SAP identifiers the way they produce plausible citations.
STRING where CHAR belongs
Python has one string type, so models reach for TYPE string. ABAP's fixed-length types pad and truncate, and DDIC fields expect them.
Index-driven loops
Tracking SY-TABIX by hand is a for-i loop wearing ABAP syntax. LOOP AT ... ASSIGNING says the same thing and is faster.
Declarations without a type
A habit from dynamically typed languages. ABAP will pick a default for you, and it is rarely the one you meant.
Your code does not leave the browser
Everything above runs client-side: the parser, the linter, the transpiler and the execution sandbox are all JavaScript in your tab. There is no backend to send anything to, and no LLM API is called — the pitfall rules are static analysis, not a model asking a model. That matters if what you are checking came out of a consulting engagement rather than a tutorial.
The one exception is deliberate and visible: the Share button encodes your source into the URL, so share links do carry it. Nothing else does.
What this cannot tell you
Worth being blunt about, because a green report is not a promise that the code is correct for your system.
- Whether your tables and fields exist. There is no DDIC here, so Open SQL against your own tables cannot be resolved.
- Whether a real SAP class behaves as the model claimed. Only a small set of standard classes exists in the browser runtime. An unknown one is flagged as unknown, which is not the same as knowing what the real one does.
- Business correctness. Code can pass all four stages and still compute the wrong number.
- Anything above ABAP 7.02 syntax without downporting first — that is a limit of the transpiler, not of your code.
What it does tell you is whether the code is ABAP, whether it runs, and whether it carries the fingerprints of a model guessing. That is most of the review you would otherwise do by hand.