ABAP

LLM Generated ABAP Code: Quality and Review Guide

Oktay Ateş 23 May 2026 7 min read

LLM generated ABAP code is already happening on your team — whether you've sanctioned it or not. Developers are pasting snippets from ChatGPT, Claude, or Joule into their local objects, tweaking them, and shipping. The question isn't if AI writes ABAP anymore. It's whether you have a sane review process for what it produces.

I've spent the last year reviewing AI-generated ABAP across several S/4HANA projects, and the patterns are consistent. The good news: LLMs can genuinely accelerate boilerplate-heavy work. The bad news: they fail in ways that are subtle, SAP-specific, and occasionally catastrophic if you don't know what to look for.

This guide gives you a concrete review workflow, the quality patterns that separate trustworthy AI output from dangerous output, and an honest answer to the question: when should you actually trust it?

Why LLM Generated ABAP Code Fails Differently Than Human Code

Before we get into review checklists, you need to understand how LLMs fail at ABAP. It's not random. There are structural reasons.

Modern LLMs were trained on vast public codebases. ABAP has a fraction of the public training data that Java or Python has. SAP-specific APIs — BAPI signatures, function module parameters, RAP framework conventions — are underrepresented. The model fills gaps with plausible-looking code that compiles but behaves wrongly at runtime.

The second failure mode is version blindness. An LLM might generate perfectly valid ABAP 7.31 syntax when your system runs 7.57. It might use SELECT * into a work area when you're on HANA and should be using inline declarations with field lists. It doesn't know your system's release level unless you tell it explicitly.

Third, and most dangerously for SAP systems: LLMs don't understand transactional context. They'll happily generate a COMMIT WORK inside a function module that's called from a larger LUW. They'll open a database cursor without closing it. They'll bypass the locking mechanisms your business process depends on.

The Four Quality Tiers of AI-Generated ABAP

After reviewing hundreds of AI-generated snippets, I categorize output into four tiers. Knowing which tier you're looking at determines how much review effort to invest.

Tier 1 — Safe to Accept with Light Review

These are purely algorithmic tasks with no SAP-specific API surface:

String manipulation with ABAP built-ins (CONCATENATE, SPLIT, string expressions)
Internal table sorting, filtering, looping with LOOP AT ... WHERE
Simple data type conversions
Date/time arithmetic using standard ABAP functions
Straightforward IF/CASE logic trees

Here, LLMs perform well. The ABAP syntax is well-represented in training data, and there's no hidden SAP-specific behavior to get wrong. A quick syntax and logic check is sufficient.

Tier 2 — Review Carefully Before Accepting

OpenSQL SELECT statements (field lists, JOIN conditions, WHERE clauses)
Class and interface definitions, method signatures
Exception class hierarchies
Simple BAPI calls with well-known function modules like BAPI_SALESORDER_GETLIST

LLMs get these right often but not always. The OpenSQL output frequently uses deprecated syntax or ignores HANA-specific performance implications. Always check actual field names against the data dictionary — LLMs hallucinate field names with uncomfortable regularity.

Tier 3 — Treat as a Draft, Rewrite Significant Portions

RAP behavior implementations (managed/unmanaged handler classes)
CDS view definitions with complex annotations
Authorization checks using AUTHORITY-CHECK
Enqueue/dequeue locking logic
BAPI transaction bundling with BAPI_TRANSACTION_COMMIT

In this tier, the AI gives you structure you can work from, but the details will be wrong in ways that matter. Use the output to understand what code you need to write, not as code you'll ship.

Tier 4 — Don't Use, Write From Scratch

Dialog programming (screens, PBO/PAI modules)
Spool and print workbench integrations
Complex LUW choreography across multiple function modules
Anything touching SAP's internal kernel APIs

LLMs have poor coverage of these areas. The output looks plausible but contains systemic errors. It's faster to write from scratch using documentation than to untangle the AI's confident mistakes.

A Practical Review Workflow for LLM Generated ABAP Code

Here's the workflow I use and teach. It's designed to fit into a normal code review process without adding days of overhead.

Step 1: Classify the Tier Before Reading the Code

Look at the ticket or the prompt that generated the code. What domain is it in? Map it to the tier above in thirty seconds. This determines how deeply you read.

Step 2: Check the Syntax Context

Run the code through the ABAP syntax check in SE80 or ADT. This catches the obvious problems. But don't stop here — syntax-clean code can still be semantically broken.

Step 3: Verify All External References Against the Data Dictionary

Every table name, field name, function module, and class reference needs to be verified against your actual system. This is non-negotiable. I've seen LLMs invent field names that don't exist — VBAK-KUNNR2 doesn't exist, but it looks plausible enough that it gets missed in fast reviews.

In ADT, use code completion to validate. If the field doesn't autocomplete, it doesn't exist.

Step 4: Audit the Transaction Handling

Search the generated code for every occurrence of:

COMMIT WORK / ROLLBACK WORK
CALL FUNCTION ... IN UPDATE TASK
ENQUEUE_ / DEQUEUE_ function modules
BAPI_TRANSACTION_COMMIT

For each one, ask: does the caller of this code expect to own the LUW, or is this object allowed to commit independently? LLMs default to committing eagerly. In SAP development, that's almost always wrong in reusable components.

Step 5: Check Performance Patterns

On HANA systems, these SQL patterns from AI output will hurt you in production:

" Bad — LLM commonly generates this
SELECT * FROM vbak INTO TABLE @DATA(lt_orders)
  WHERE erdat = @lv_date.

" Better — explicit field list, inline declaration
SELECT vbeln, kunnr, audat, netwr
  FROM vbak
  INTO TABLE @DATA(lt_orders)
  WHERE erdat = @lv_date
  AND vbtyp = 'C'.

Also watch for nested SELECTs inside LOOPs — LLMs generate these constantly, and they are catastrophic on large datasets. If you're dealing with OpenSQL performance at scale, the patterns covered in SAP ABAP Performance Optimization apply directly to AI-generated code review.

Step 6: Review Error Handling Explicitly

LLMs generate optimistic code. They handle the happy path and forget the error path. Check that every BAPI call reads the RETURN table and acts on error messages. Check that every database operation has appropriate error handling. Check that exceptions are not swallowed silently.

" LLM commonly generates — no error handling
CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'
  EXPORTING
    order_header_in = ls_header
  TABLES
    return          = lt_return.

" What you actually need
CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'
  EXPORTING
    order_header_in = ls_header
  TABLES
    return          = lt_return.

READ TABLE lt_return WITH KEY type = 'E' TRANSPORTING NO FIELDS.
IF sy-subrc = 0.
  " Handle error — raise exception, log message, rollback
  RAISE EXCEPTION TYPE zcx_sales_order_error
    EXPORTING
      return_table = lt_return.
ENDIF.

For a deeper treatment of exception architecture, the ABAP exception handling guide shows the patterns that pair well with AI-generated business logic.

Step 7: Run It Against a Unit Test

If the generated code is a class method or function module, write at least one unit test before accepting it. The discipline of writing a test forces you to think about the interface contract — inputs, expected outputs, edge cases. LLM-generated code often fails on edge cases (empty tables, null values, date boundaries) that a basic test exposes immediately.

The ABAP unit testing guide covers the test infrastructure you need for this step. And if you're building mocks for dependencies, test doubles and mocking is directly applicable.

Prompting Strategies That Improve Output Quality

Review burden drops significantly when you give the LLM better context upfront. These prompting patterns consistently improve ABAP output quality:

Always Specify Your ABAP Release

Start every prompt with: "I'm working on SAP S/4HANA 2023 with ABAP 7.57. Use modern ABAP syntax with inline declarations, string expressions, and OpenSQL with host variables."

Without this, you get a mix of old and new syntax that's inconsistent and sometimes incompatible.

Provide the Real Data Dictionary Objects

Paste the actual table structure or field list from SE11 into the prompt. Tell the model exactly which fields exist. This eliminates hallucinated field names at the source.

Specify the Transactional Context

Tell the model whether it's writing a reusable method (no commit), a batch job (owns the LUW), or a RAP action (framework handles commit). The model will adjust — but only if you tell it.

Ask for Error Handling Explicitly

Add to your prompt: "Include full error handling. Raise class-based exceptions on failure. Do not use sy-subrc checking as the only error mechanism."

When to Trust LLM Generated ABAP Code

Here's my honest take after a year of this:

Trust it for scaffolding, not for logic. AI is excellent at generating class skeletons, interface stubs, repetitive getter/setter methods, and boilerplate that would take you twenty minutes to type. Use it for exactly that. The moment the logic has real business rules, real SAP integration points, or real transactional requirements, treat AI output as a first draft that needs experienced review.

Trust it more as your team builds prompt libraries. If your team standardizes on prompts that include system release, data dictionary context, and architectural constraints, output quality improves enough that Tier 2 code often approaches Tier 1 reliability. This is worth investing in.

Never trust it on authorization and locking. These two areas are where incorrect AI code creates security vulnerabilities or data corruption that's hard to diagnose. AUTHORITY-CHECK logic and enqueue patterns need to be written by someone who understands SAP's authorization model, period. The ABAP API authentication patterns article covers some of this context for integration scenarios.

Trust it more for greenfield than brownfield. In new development without complex existing dependencies, AI-generated code has fewer ways to interact badly with existing systems. In legacy enhancement scenarios, the blast radius of a wrong assumption is much larger.

Building a Team Culture Around AI-Assisted ABAP Development

The teams I've seen handle this well share a few practices:

They mark AI-generated code explicitly. A simple comment "* AI-assisted — reviewed by [name] [date]" in the code tells the next developer what they're looking at and creates accountability.

They don't skip code review because AI wrote it. If anything, AI-generated code gets more scrutiny in the first six months, until the team understands where their specific LLM reliably fails.

They keep a failure log. Every time AI-generated code causes a bug in testing or production, they document it. After a few months, patterns emerge that sharpen your review instincts and your prompting strategy simultaneously.

They use AI for the right parts of the workflow. The clean code principles from the ABAP clean code refactoring guide still apply to AI output. Good code structure doesn't change because a model wrote the first draft.

Final Thought

LLM generated ABAP code is a productivity tool, not a replacement for ABAP expertise. The developers who get the most out of it are the ones who understand ABAP deeply enough to catch what the AI gets wrong. The ones who get burned are the ones who ship AI output without that expertise in the review loop.

Build the review workflow. Build the prompting standards. Keep a senior eye on the output. Do that, and AI becomes a genuine accelerator for your SAP development team — not a liability waiting to surface in production.