SAPCodeMonkeyHow SAP Skills Change by Role
Clean core, AI tooling and continuous change are arriving together. The value moves from producing work to judging it — and what that means depends entirely on which seat you are in.
Three forces are arriving in SAP work at the same time, and while each on its own would be manageable, together they reshape the job. This article sets out what those forces are, the single pattern underneath all of them, and — seat by seat — what changes for developers, functional consultants, and support and Basis staff, with a practical twelve-month path for each.
Three forces, arriving together
The first is clean core. Custom code is moving out of the core and onto released APIs, which means decades of modifications need rebuilding or retiring. The second is AI tooling: generation has become cheap, so the scarce skill is no longer producing code or configuration but judging whether the output is correct, fast and upgrade-safe. The third is continuous change — a cloud release cadence replacing the old three-year upgrade cycle, so nothing is ever truly finished.
None of these removes the need for people who understand why a system behaves the way it does. What they do is move the value from producing work to judging it.
The pattern, in every seat
That shift is the single most useful idea here, and it applies identically across all three roles. For a developer, it is the move from writing the code to knowing whether it is right. For a functional consultant, from configuring to the specification to shaping the specification. For support, from closing the ticket to understanding why it keeps reopening. Same idea, three seats.
Developers
What loses value is honest to name: memorising function modules and syntax, raw speed at boilerplate, classic-only depth, and writing code a model now produces in seconds. If a developer's entire professional identity is writing ABAP quickly, that is the part under pressure.
What gains value is the more interesting half of the job. Judging output for performance, correctness and upgrade safety. Set-based thinking — pushdown, CDS and AMDP over loops. Clean core patterns: ABAP Cloud, RAP and released APIs. And reading legacy code to decide what to keep and what to kill. The developer who has debugged a production dump at two in the morning is precisely the person who can supervise a tool that is fast and occasionally, confidently wrong.
The twelve-month path is one meaningful step per quarter, all achievable alongside a full workload: get graded by running ATC readiness checks on your own code; learn CDS properly and convert one loop-heavy report to pushdown, measuring the before and after; build one small business object end to end in RAP; then take one extension side-by-side on BTP, using AI tooling daily to learn precisely where it is wrong.
Functional consultants
This is the seat that gains the most, and the one most people underestimate. What fades is transaction-code knowledge as the core professional skill, configuration by rote in newly standardised areas, and the role of translator between business and developers. What grows is knowing exactly what standard already does — which is pure leverage — alongside reading and reasoning about generated code, launchpad and catalog design as a user-experience decision, and deciding where automation acts and where a human signs off.
The path is built around one principle: never specify a custom build for something standard already does. Learn the data model in your area; map every standard Fiori app in your module and build your own catalog of what exists; extend without a developer using key-user tools; then design a process, writing the governance rule rather than just the configuration. The catalog exercise pays for itself the first time it stops an unnecessary development.
Support and Basis
This seat feels the most exposed and is actually holding one of the strongest hands. Answering “what is the transaction code” fades; so does manual repetitive checking and the annual upgrade-project rhythm. What grows is gatekeeping what reaches production — more code, arriving faster, from more people — along with governance and audit trails for automated decisions, launchpad and role diagnosis, and continuous release management. The highest-value work of all is governing autonomy: audit trails for agent-driven steps, and segregation of duties where systems act alone. Technology can route and it can decide. It cannot own accountability.
What all three need
Four things hold value regardless of seat: domain depth, which does not automate; AI fluency, meaning knowing what these tools do well and where they are confidently wrong; judgment — reviewing, deciding, saying no; and communication, turning business intent into a specification and technical reality back into something a stakeholder can act on. Three of those four cannot be taught by a course. They are earned by doing the work, which means anyone with years in these systems already holds most of what matters.
The honest risk
The floor is rising and the middle is being squeezed. What is genuinely exposed is commodity delivery — routine reports, headcount billed by the day, work defined entirely by a ticket queue. But the response is not resisting the tools or waiting for it to blow over. The people who treat this as a threat to avoid get outcompeted by people with identical experience who treat it as leverage. Same person, different response, completely different next five years.
Sources & further reading
- SAP Help — Extensibility (on-stack & side-by-side)The released-API model underpinning the shift from writing code to judging it. Verified live.
- SAP Community — S/4HANA topic hubOngoing practitioner discussion across all three roles. Verified live.
SAP guidance, transaction availability and dates change between releases and editions. Verify anything here against SAP Help for your own situation before you commit to it. This article is independent commentary and is not affiliated with SAP or any implementation partner.