I’ve just finished following the SAP TechEd Berlin sessions virtually, and if I had to sum up the ABAP story in one sentence, it would be:
“ABAP is not dead at all. It’s getting cloud-native, low-code-friendly, and now it’s getting an AI brain.”
This post is not formal advice or a project recommendation for any specific company.
It’s simply my personal reflection on what I heard, how I understood it as an ABAP/AI developer, and what I’m planning to learn next.
Let me tell the story the way I would in the office kitchen with a coffee in hand.
1. ABAP Cloud: this is where SAP wants us to live
The first message felt very clear:
If you’re building new things, SAP wants you in ABAP Cloud.
No drama, no “classic vs. cloud wars,” just a direction:
- One ABAP platform runs S/4 on-prem, S/4HANA Cloud, and BTP ABAP.
- New features land first in BTP ABAP (Steampunk) and then flow into S/4.
- Classic ABAP is still there — but mostly for existing stuff. New things? ABAP Cloud model.
They also showed a “clean core levels” picture that I really liked because it’s easy to remember:
- Level A – pure ABAP Cloud with released APIs and RAP.
- Level B – classic ABAP, but still using allowed APIs.
- Level C/D – wild west: internal stuff, direct table access, modifications.
And you could feel the subtext:
“All the good tooling and AI help is going to be optimized for A and B.
If you’re in C/D, we won’t forget you, but you’re not on the fast lane.”
For me personally, that just confirms something I already suspected:
if I want to benefit from SAP’s future AI tools around ABAP, I should invest my learning time in ABAP Cloud and RAP, not in pushing clever tricks into Level C/D.
2. SAP Build and ABAP Cloud: not either/or, but “together”
Another big theme was how SAP Build and ABAP Cloud fit together.
I’d describe it like this:
- SAP Build is where low-code people sketch apps, workflows, and simple scenarios.
- ABAP Cloud is where you put the serious backend logic, the “don’t break finance” stuff.
- They are meant to work together, not compete.
A few things that stood out to me:
Quick Fiori apps from RAP
From the ABAP side, they showed how you can:
- Define a RAP business object (CDS, behavior, etc.).
- Set up a service binding with the right annotations.
- Click a few times and get a ready-to-run Fiori Elements app — list report, object page, tile, everything wired.
No separate UI project, no “hello world” manual wiring.
If you want, you can later export a project and tweak it, but you don’t have to.
For me, this fits perfectly with where AI is going:
- RAP + annotations define the structure,
- SAP tools generate the UI,
- and in the near future, SAP-ABAP-1 can help write the RAP and annotations faster.
Graphical modeling in SAP Build
From the SAP Build side, they showed a graphical way to:
- Draw entities and relationships,
- Define projections and services,
- Generate a full RAP service + UI service from that design.
So you can imagine a team where:
- A more “business-minded” person models things visually in SAP Build,
- The ABAP dev refines the behavior and deeper logic,
- and AI fills in a lot of boilerplate in between.
That’s the pattern I see emerging, even if it will take a few releases to mature.
3. SAP-ABAP-1: ABAP finally gets its own AI model
Now to the piece that made a lot of ABAP folks sit up straight: SAP-ABAP-1.
This model wasn’t explained in every slide, but the overall picture is fairly clear:
- It’s a foundation model trained specifically on ABAP code (SAP’s own code base).
- It lives in SAP AI Foundation, inside the generative AI hub.
- It’s meant for ABAP AI use cases and developer productivity — not generic chit-chat.
If you’ve used generic copilots before, you already know the problem:
they can help, but they don’t really “think in RAP,” they don’t know SAP naming rules, and sometimes they produce ABAP that looks okay but wouldn’t survive ATC.
SAP-ABAP-1 aims to fix that by understanding:
- RAP patterns,
- ABAP Cloud rules,
- SAP’s typical ways of structuring things.
What kind of help do I realistically expect from it?
Day-to-day help
Things like:
- “Generate a RAP BO for this entity with fields A/B/C, including draft handling.”
- “Add the annotations needed for a basic Fiori list report with filters for these fields.”
- “Explain what this 20-year-old Z-program does, in plain language.”
- “Suggest a modern ABAP Cloud version of this classic SELECT/ENDSELECT block.”
So not science fiction — just the things we already do, but hopefully faster and less painful.
Clean-core and migration help
Another angle is migration:
- Analyzing custom code,
- Classifying what’s clean and what’s risky,
- Suggesting how to move logic out of the core into proper extensions.
There was even a slide about an “ABAP AI application” that sits side-by-side with S/4HANA Cloud private edition and helps with exactly that: understanding and transforming custom code.
Under the hood, it’s very natural to imagine SAP-ABAP-1 doing the reading and explaining, while tools and reports present the results.
ABAP coding agents
And then there’s the “agents” idea.
They showed a vision of ABAP coding agents – small AI helpers that:
- Have access to tools like “Explain,” “Refactor,” “Generate tests,” etc.
- Work towards a target, for example:
- “Bring this package closer to clean-core level A/B,”
- or “Increase ATC compliance in this area.”
In that picture:
- The agent is the orchestrator,
- SAP-ABAP-1 is the brain for understanding and producing ABAP,
- and other tools (ATC, CVA, transports, etc.) provide guardrails and checks.
It’s still a roadmap slide, not a product I can use today, but it gives a good sense of where SAP wants to go.
4. VS Code enters the ABAP story
One more important change: ABAP is coming to VS Code.
Right now, most of us live in ADT / Eclipse. SAP isn’t killing that, but they clearly want to add:
- a VS Code extension for ABAP Cloud,
- initially focused on Fiori + ABAP Cloud scenarios.
Why does that matter?
Because VS Code is where a lot of AI tooling already lives.
If SAP-ABAP-1 plugs into that, it’s easy to imagine a future where you:
- Open your RAP project in VS Code,
- Right-click a method → “Explain with ABAP AI,”
- Or trigger a command → “Generate RAP behavior for this CDS entity,”
- and behind the scenes, the extension talks to SAP AI Foundation and SAP-ABAP-1.
It’s not there yet, but the path is drawn.
5. What I’m personally taking from all this
This last part is important:
I’m not telling any company what they should do.
I’m just summarizing how I plan to adjust my own learning and side projects after TechEd.
If I strip away all the buzzwords, here’s what I’m taking home as a developer/architect:
- New code → ABAP Cloud by default (for my own designs)
When I sketch new examples or PoCs, I try to start with RAP, released APIs, and the ABAP Cloud language version. It makes my learning future-proof and keeps me close to where SAP is investing. - SAP-ABAP-1 as the “code brain” in my mental architecture
In my head, I separate:- models that understand business data (like SAP-RPT-1 or others), and
- models that understand ABAP code (SAP-ABAP-1).
- SAP Build is a partner, not a threat
I don’t see SAP Build as replacing ABAP work.
I see it more like a canvas where business and low-code people can sketch flows and UIs, while ABAP Cloud holds the serious logic. That helps me think about how to design APIs and services that are easy to consume. - Clean-core is now tied to AI, not just to upgrades
The more code sits in Level A/B (clean ABAP Cloud patterns), the easier AI tools and agents can help with it. That changes clean core from “just a governance topic” into “something that will directly impact how useful SAP-ABAP-1 and future tools are.”
These are my personal conclusions and learning goals, based on public TechEd content and my understanding of SAP’s roadmap.
They are not a substitute for a proper assessment of any specific SAP landscape — but if you’re also exploring ABAP Cloud and SAP’s new AI tools, maybe this perspective helps you organize your own thoughts too.