Hallucinated Class Names

Ask an AI to convert a currency and it may reach for CL_CURRENCY_CONVERTER. The name follows SAP's conventions exactly, the method signature looks reasonable, and the class does not exist. This is the single most expensive AI mistake in ABAP, because you cannot tell by reading.

Detected as: llm-hallucinated-class · severity error

Possibly hallucinated class or interface name

Why ABAP gets this worse than other languages

A language model generates the most plausible next token. SAP's naming is extremely regular — CL_ for classes, IF_ for interfaces, ABAP in the middle of utility classes — so producing a convincing name is easy. Producing a real one requires having memorised a repository of hundreds of thousands of objects, most of which never appear in public code.

Python has the opposite situation: its standard library is small, universally documented and everywhere in training data. ABAP is a low-resource language for these models, and this is where that shows up most sharply.

Real, or invented?

Worth trying before you scroll: which of these exist?

CL_ABAP_TYPEDESCR
CL_ABAP_STRING_UTILITIES
CL_STRING_HELPER
CL_ABAP_UNIT_ASSERT
CL_JSON_SERIALIZER
CL_ABAP_CONV_OUT_CE

The third and fifth are inventions of the sort models produce; the rest are real SAP classes. If you had to think about it, that is the point — plausibility is not evidence, and no amount of code review catches this. Only a system, or a documented list, can answer it.

How to check, in order of cost

On a system: open it in SE24 or ADT. Definitive, and takes seconds.
Without one: search SAP's official ABAP keyword documentation or the class in open-abap-core, which reimplements the commonly used ones.
Here: paste the code into the AI Validator. Unresolvable CL_, IF_, ZCL_ and ZIF_ names are flagged.

Note the direction of the check here: a flag means "this could not be resolved", which for a Z-class from your own system is expected and fine. Treat it as a prompt to verify, not a verdict.

What to do instead while prototyping

If what you are actually testing is your own logic, do not depend on a standard class at all. A local class always exists, because you define it in the same program — so it runs anywhere, including in a browser.

" Instead of a CL_* you are not sure about
CLASS lcl_greeter DEFINITION.
  PUBLIC SECTION.
    METHODS greet
      IMPORTING iv_name        TYPE string
      RETURNING VALUE(rv_text) TYPE string.
ENDCLASS.

CLASS lcl_greeter IMPLEMENTATION.
  METHOD greet.
    rv_text = |Hello, { iv_name }!|.
  ENDMETHOD.
ENDCLASS.

Then swap in the real standard class once you are on a system and have confirmed its name and signature. Wrapping the dependency behind your own interface makes that swap a one-line change — and makes the logic testable with ABAP Unit either way.

A prompting habit that helps

Ask for the standard-class dependency to be named and isolated rather than sprinkled through the code: "use only local classes, and list separately any SAP standard class you would normally call". You get code that runs, plus an explicit list of things to verify — instead of a single blob where the two are indistinguishable.

Run the local-class version →