A Wish for CLI-Based ABAP
Lately I’ve been thinking a lot about where SAP development is heading — and where it feels like it isn’t.
Outside the SAP ecosystem, development has moved decisively toward text-based, terminal-driven workflows. Code lives in Git, workflows start in the CLI, automation is the default, and AI tools increasingly operate directly on source files.
Inside the SAP world, especially around extensibility, we often see the opposite: GUI-driven tools, browser-based editors, and logic that gets generated somewhere behind the scenes.
After working hands-on with extensibility in S/4HANA recently, that contrast became impossible to ignore. It led to a simple but persistent thought:
What if ABAP fully embraced a CLI-based, developer-centric development model?
Modern development has moved to the terminal
For many developers today, the terminal isn’t a niche preference — it’s the center of gravity.
Modern development typically means:
source code as plain text
Git as the system of record
the terminal as the control plane
automation and pipelines by default
AI tools working directly on repositories
Tools like Claude Code make this very tangible. You can sit in a terminal, point the AI at a repository, ask it to explain a codebase, refactor a module, or generate a patch — all as diffs against real files. No wizards, no GUIs — just text in, text out.
Once you get used to working this way, it’s hard not to expect the same experience everywhere.
ABAP lives in a different world
ABAP, by contrast, still revolves around the SAP system itself.
Code primarily lives in the database
The system is the source of truth
Changes move via transports
Git integration is optional, secondary, and often awkward
Development assumes a running backend, not a repository
Even tools like abapGit, as valuable as they are, don’t change this fundamental model. They bridge worlds — they don’t redefine which world ABAP belongs to.
This means ABAP is not Git-centric. It’s not repository-centric. And as a result, it doesn’t naturally fit into modern CLI-based or AI-assisted workflows.
Low-code doesn’t fix this — it exposes it
SAP’s clean-core strategy has pushed heavily toward Key User Extensibility:
From a governance and upgrade perspective, this makes sense.
From a developer perspective, it often highlights the core problem.
Custom Logic is still ABAP — typed, structured, technical — but:
written in browser editors
without proper refactoring or navigation
without native Git ownership
without automation-friendly workflows
It ends up in an awkward middle ground:
Low-code doesn’t remove the need for strong developer workflows. It makes the absence of them more visible.
Clean core needs better developer ergonomics, not less code
Clean core is the right goal. There’s no debate there.
But clean core should not mean:
In practice, clean core works best with:
All of that aligns far better with CLI-friendly, developer-centric workflows than with click-driven configuration.
“CLI-based ABAP” is shorthand for a deeper change
When developers ask for CLI-based ABAP, they’re not chasing trends. And looking at how CAP is designed, SAP also knows this.
They’re really asking for:
ABAP source as first-class text
Git as a native concept, not a side channel
syntax checks, ATC, and tests callable from automation
workflows that don’t require a GUI or heavy IDE
AI tools that can reason about ABAP like any other language
This doesn’t mean pretending SAP systems aren’t special.
It means acknowledging that system-centric development no longer scales.
Why VS Code actually matters
This is why SAP’s move toward VS Code support for ABAP is so interesting.
VS Code isn’t just another editor. It sits at the center of:
Git-first workflows
terminals
automation
AI-assisted development
If ABAP can genuinely move closer to that ecosystem — even gradually — a lot suddenly becomes possible:
VS Code isn’t the goal.
It’s a signal.
Bluesky
