YourSAPCustomCodeIsYourBiggestAIAdvantage

Your SAP system already contains decades of business knowledge

Ask a company where its SAP documentation is stored and you may hear:

Confluence. SharePoint. Solution Manager. Jira. Architecture documents. Functional specifications.

All of these answers are correct.

But they are incomplete.

A significant part of the company’s real operational knowledge is stored somewhere else:

inside the SAP system itself.

In custom ABAP. In enhancements. In BAdIs. In custom tables. In interfaces. In mappings. In validation logic. In thousands of small exceptions introduced over many years.

Enterprises often describe this landscape using one term:

Technical debt.

And much of it certainly is.

But from the perspective of AI, there is another way to look at it.

Your custom SAP landscape is also a machine-readable record of how your company learned to operate.

That makes it potentially one of your most valuable sources of context for enterprise AI.

The code contains the decisions

Consider a seemingly strange condition in an ABAP program:

IF lv_country = 'DE'
   AND lv_customer_type = '02'
   AND lv_valid_from < '20210401'.

  " special processing

ENDIF.

A developer looking at this code today may ask:

Why does this exist?

The answer may not be obvious.

Perhaps five years ago:

• a major customer required different billing logic,
• a migration created a temporary exception,
• a legal requirement changed,
• an integration behaved differently for historical contracts,
• or a production incident forced the team to introduce a workaround.

The developer who implemented it may have left the company.

The functional consultant may be working on another project.

The Jira ticket may be closed.

The documentation may be outdated.

But the logic remains.

The code is evidence that a business decision was made.

Legacy SAP is an undocumented knowledge graph

A mature SAP landscape is not simply a collection of programs.

It is a network.

Most organizations do not have this graph explicitly documented.

But fragments of it already exist across enterprise systems.

The challenge is reconstructing it.

Historically, humans did this manually.

A senior SAP consultant receives an incident and starts exploring:

• Which process is this?
• Which interface is involved?
• Which enhancement handles this case?
• Who changed it?
• Was there a related incident?
• What customizing affects it?
• Which table contains the relevant data?
• What happens if we change this condition?

This investigative process is one of the most valuable skills of an experienced SAP engineer.

It is also exactly the type of problem AI agents may become very good at solving.

The limitation of today’s coding assistants

Modern coding agents are impressive.

Give them a repository and they can:

• explain code,
• generate code,
• refactor,
• create tests,
• review changes,
• search files.

This works particularly well in modern software projects where much of the system exists in Git.

SAP is different.

A large SAP landscape cannot be understood from a source repository alone.

The real system includes:

ABAP source code
+ DDIC
+ CDS
+ Enhancements
+ Customizing
+ Transports
+ Runtime data
+ Application logs
+ Interfaces
+ AIF
+ Background jobs
+ Authorizations
+ Historical incidents
+ Functional documentation
+ Business decisions

A coding agent that sees only ABAP files sees only one part of the picture.

From coding agent to SAP engineering agent

This distinction matters.

A coding agent asks: How should I change this code?
A SAP engineering agent should first ask: Why does this code exist, what depends on it, and what will happen if I change it?

That requires much more context.

The second model is much closer to how experienced SAP teams actually work.

What does the agent need to understand?

Imagine we give an agent a requirement:

Add a new validation for Provider Contract creation for customer group X.

A useful agent should not immediately generate ABAP.

First, it needs to explore the system.

It may need to identify:

• the relevant business process,
• existing validation logic,
• interfaces involved,
• classes and function modules,
• enhancement implementations,
• related CDS views,
• relevant customizing,
• existing tests,
• previous changes,
• similar implementations,
• production incidents associated with the process.

Only then should it propose an implementation.

This changes the workflow fundamentally.

The new SAP development loop

Traditional AI coding often looks like this:

Prompt
↓
Generate Code
↓
Developer Reviews

An enterprise SAP agent should operate differently.

Notice where code generation happens.

Relatively late.

That is intentional.

For enterprise SAP systems, understanding the change is often harder than writing the code.

Example: a production incident

Consider an incident:

Sales Quantity creation fails for customers with overlapping promotional periods.

A traditional support process might involve several people.

The support engineer checks the error. The functional consultant investigates the business scenario. An integration specialist checks the inbound payload. An ABAP developer searches for the implementation. Someone looks for previous incidents.

Eventually the team discovers the relevant logic.

Now imagine an agent receives the same incident.

Step 1 - Start from the incident

The agent retrieves:

• error description,
• timestamps,
• affected business objects,
• interface information,
• user comments,
• previous investigation.

It identifies the relevant SAP process.

Step 2 - Inspect runtime evidence

The agent checks:

• application logs,
• AIF messages,
• payload,
• mapped structures,
• relevant business object data,
• error stack.

It determines where the processing stopped.

Step 3 - Discover the implementation

The agent follows the technical path.

Instead of asking a developer to manually search the landscape, the agent builds the dependency path.

Step 4 - Ask the most important question: why?

The agent finds a condition related to promotional validity periods.

But finding code is not enough.

It searches historical context.

It discovers:

• the transport that introduced the logic,
• the associated requirement,
• a Jira ticket,
• two previous incidents,
• and a design decision explaining the original behavior.

Now the agent understands not only what the code does but also why it exists.

This is where enterprise AI becomes much more interesting.

Step 5 - Build an impact map

Before modifying anything, the agent identifies potential impact.

The engineer can now review the change with significantly more context.

Step 6 - Generate the implementation

Only after understanding the landscape does the agent prepare the code change.

It can:

• modify the relevant implementation,
• follow existing project conventions,
• reuse similar patterns already present in the system,
• update tests,
• document the reason for the change.

The objective is not simply to produce syntactically correct ABAP.

The objective is to produce a change consistent with the existing SAP landscape.

Step 7 - Validate before asking for human attention

The agent can then execute available validation steps:

• syntax check,
• activation checks,
• ATC,
• ABAP Unit,
• scenario-specific tests,
• static analysis,
• comparison against acceptance criteria.

Instead of presenting a developer with raw generated code, it can present a decision package.

This is a very different interaction from autocomplete.

The real opportunity: turn legacy into context

For years, SAP transformation programs have focused on reducing custom code.

And rightly so.

Unnecessary customization increases:

• upgrade complexity,
• maintenance cost,
• technical risk,
• migration effort.

AI does not make bad custom code good.

But AI changes the economics of understanding large custom landscapes.

Historically, understanding thousands of custom objects required enormous human effort.

An agent can potentially analyze them continuously.

That creates a new perspective.

The legacy landscape stops being only something the organization has to maintain.

It becomes context the agent can learn from.

From tribal knowledge to corporate knowledge

There is another major benefit.

Every large SAP organization has people who seem to know things nobody else knows.

Someone knows why billing works in a particular way. Someone remembers an integration decision made in 2019. Someone knows which enhancement must never be touched. Someone remembers why a table contains a strange status.

We often call this:

tribal knowledge.

It is valuable and fragile.

When experienced consultants leave, part of the system’s real documentation leaves with them.

AI agents create an opportunity to connect human knowledge with technical evidence.

Instead of repeatedly explaining the same system to every new consultant - or every new AI conversation - the organization builds persistent system knowledge.

The agent should learn the company, not only SAP

Foundation models already know a great deal about ABAP and SAP concepts.

That is useful.

But every enterprise SAP system is different.

The real competitive value comes from understanding:

SAP standard
+ your custom code
+ your configuration
+ your integrations
+ your history
+ your incidents
+ your architecture decisions
+ your business processes

Generic SAP knowledge tells an agent how SAP normally works. Corporate context tells it how your SAP works.

That difference is critical.

Why this matters for S/4HANA transformation

This approach is not limited to maintaining ECC.

It can also change how organizations approach S/4HANA transformation.

One of the first questions in a transformation is:

What custom code do we actually have and why does it exist?

Traditional analysis can identify technical facts:

• unused objects,
• incompatible code,
• modifications,
• custom developments,
• dependencies.

But the harder question is business relevance.

• Why was this development created?
• Which business process depends on it?
• Is the requirement still valid?
• Does S/4HANA standard now provide the capability?
• Can the customization be removed?
• Should it be redesigned?

An AI agent combining technical analysis with historical enterprise context could help answer these questions.

This can turn AI from a code generator into a transformation analysis tool.

But the agent needs controlled access

Giving an agent this level of understanding requires access to sensitive enterprise information.

Potentially:

• source code,
• system metadata,
• business data,
• incident history,
• internal documentation,
• integration architecture.

That means system understanding and agent governance cannot be separated.

The more capable the agent becomes, the more important it is to control:

• identity,
• permissions,
• system access,
• knowledge boundaries,
• tool execution,
• approvals,
• audit history.

This is why we believe the future architecture is not simply:

SAP → LLM

It is:

SAP Landscape
+ Corporate Knowledge
+ Historical Context
        ↓
Governed Agent Runtime
        ↓
SAP Engineering Agent
        ↓
Analysis
        ↓
Proposed Change
        ↓
Tests
        ↓
Human Approval
        ↓
Execution

Where AgentOS fits

At Codemine, this is the problem we are working on with AgentOS.

Our goal is not to build another chatbot that knows SAP terminology.

The goal is to create an environment where enterprise agents can progressively understand the customer’s actual SAP landscape.

That means connecting agents to:

• ABAP development environments,
• custom code,
• SAP metadata,
• runtime information,
• enterprise documentation,
• tickets and incidents,
• Git repositories,
• project knowledge,
• historical decisions.

While keeping execution inside a governed corporate environment.

The agent should not start every task from zero.

It should progressively operate with an understanding of the system in which it works.

The long-term shift

Software development has historically optimized the process of writing code.

AI dramatically reduces the cost of producing code.

That means another part of engineering becomes more important:

understanding systems.

In mature SAP landscapes, understanding is often the expensive part.

Finding the right enhancement. Understanding dependencies. Discovering why something exists. Assessing impact. Reconstructing historical decisions. Identifying what can safely change.

This is where AI agents can potentially create much more value than code completion alone.

Your legacy may become your advantage

For years, companies have looked at millions of lines of custom SAP code and seen primarily a liability.

That view will not disappear.

Technical debt is real.

But there is another side to the equation.

Those millions of lines also encode:

• business rules,
• exceptions,
• integrations,
• operating models,
• historical decisions,
• and years of organizational learning.

If AI agents can connect those technical artifacts with business context and history, the legacy landscape becomes something else:

a machine-readable representation of how the enterprise actually works.

And that may become one of the most valuable sources of context for enterprise AI.

The companies with the most mature systems may therefore possess something surprisingly valuable.

Not just legacy code.

The question is whether their AI agents will be able to understand it.