Ai-Abap-Development-Series on Marian Zeis Blog

Introducing ARC-1: A Secure ADT MCP Server for Enterprise SAP Development

Mon, 27 Apr 2026 09:00:00 +0200

Series note: This post is part of my AI ABAP development series, where I go from AI development in general, to ABAP-specific problems, and then to ARC-1.

In the first post of this series, I wrote about context and how I use AI in development. In the previous post, I then moved that discussion into ABAP and ended more or less with one question: what would an ADT MCP setup need to look like if you take control, identity, and security seriously from the beginning?

This post is my current answer to that question. It is called ARC-1 (ABAP Relay Connector, pronounced arc one [ɑːrk wʌn]), and yes, it is another ADT MCP server. But the important difference is not that it can talk to ADT at all. Other projects already showed very well that this is possible and useful. The difference is the architecture and the focus, which is also why the ARC-1 documentation spends a lot of space on security, authentication, deployment, and operations, not only on the tool list.

Why ARC-1 had to exist

Luckily, the community already did a lot of the hard work before ARC-1. Marcello Urbani’s abap-adt-api gave many TypeScript projects the foundation to work with ADT APIs at all, which are still not really documented in a useful way. Projects like oisee/vibing-steampunk, fr0ster/mcp-abap-adt, and DassianInc/dassian-adt already proved that MCP and ABAP development can work in practice and can be very useful. And Wouter Lemaire’s btp-sap-odata-to-mcp-server was also important for me, because it already showed a BTP-deployed and centrally managed direction much earlier, and Wouter also helped me during the ARC-1 implementation.

So ARC-1 is not me claiming that nobody solved this before. For me it is more this: the others already proved the technical possibility, and ARC-1 is my attempt to close the enterprise gap. That gap is the same one I described in the last post. In ABAP, the hard part is not only getting context into the model. It is that context access, write access, and control are tied very closely together in a real SAP landscape.

That is why I did not want to build just another local developer tool that happens to speak MCP. I wanted to build a secure ADT MCP server with a clearer security concept, more central control, and an architecture that fits better into enterprise SAP environments.

Central instead of local

For me this is probably the biggest architectural difference. Most current MCP ADT setups are still mainly local. The server runs on the developer laptop, gets configured there, stores credentials there, and then talks directly to the SAP system from there.

That is fine for trying things out. It is also fine for fast experimentation. And to be clear, ARC-1 can also run locally. That is useful for tests, local development, and simply trying the server out. But local developer setup is not the main story I care about here. The main story is central deployment.

That means one managed ARC-1 instance per SAP system, with central configuration, central security settings, central logging, and a clear operational owner. That can run on a company server, in Docker, or ideally on SAP BTP Cloud Foundry. The architecture documentation goes into the technical flow in more detail, but I will go much deeper into the BTP side in the next post, because that deserves its own post.

For me BTP is especially interesting here because it lets you reuse things that already exist in many companies anyway: XSUAA, destinations, Cloud Connector, audit services, role assignment, and the usual BTP login flow. Then the developer mostly just needs the MCP URL and the standard login, while admins and authorization teams keep control in the place where they already work.

I also do not think this is only an SAP-specific thought. Salesforce is already moving in a similar direction with hosted MCP servers and Headless 360, where more of the platform is exposed as APIs, MCP tools, or CLI commands. To me that confirms that enterprise MCP is a platform and governance topic, not only a developer convenience topic.

The reason this matters is simple. If the MCP server sits only on the laptop of an individual developer, then the architecture is also controlled there. That is exactly the part I do not find convincing for enterprise usage.

Two auth hops matter

One thing that became very clear while building ARC-1 is that there are really two completely different authentication questions. The first one is who is allowed to talk to the MCP server at all. The second one is as which user the MCP server talks to the SAP system.

That sounds obvious, but many discussions around MCP servers blur those two things together. In ARC-1, these are treated as two separate hops: MCP client -> ARC-1 and ARC-1 -> SAP. This matters because the architecture becomes much clearer after that.

For the first hop, ARC-1 can use things like API keys, OIDC/JWT, or XSUAA OAuth, depending on how and where it is deployed. For the second hop, ARC-1 can talk to SAP with Basic Auth, BTP service keys, or with Principal Propagation, depending on the target landscape.

That split is very important for enterprise usage, because it lets you separate client access control from SAP identity handling instead of hiding both behind one local config file. It also makes it easier to support different use cases. If ARC-1 is used more like a backend connector for an automation, an API key may be totally fine. If real per-user identity matters, then OAuth or XSUAA plus Principal Propagation is the much more interesting setup.

Safe by default, not allow all by default

The next big difference is that ARC-1 starts from the assumption that the default should be restrictive. Out of the box ARC-1 is read-only. It blocks free SQL. It blocks named table preview. It does not expose transport actions unless those are enabled. And even if writing is enabled, writes are still restricted to $TMP unless packages are explicitly allowed.

That last point is important to me. Yes, it makes the first setup a bit less magical. Sometimes you need to configure one more thing. But I prefer that over accidentally giving an AI assistant full write access to transportable packages because one flag was too broad.

ARC-1 also has operation allowlists and denylists, package restrictions, and safety profiles like viewer, viewer-sql, or developer. So there is not only one on or off switch. For SAP development that feels much more realistic to me than a server that starts by allowing everything and then hopes people will restrict it later.

Layered security, not just one switch

This also leads to the next point. For me, security here is not one boolean setting. It is several layers on top of each other.

At the ARC-1 level there is the server safety configuration itself: read-only mode, blocked SQL, package restrictions, operation filters, transport gates. Then there is the identity and role layer on top, for example via OIDC or XSUAA scopes and roles. And then there is still the SAP system itself with its own authorization objects and checks.

That means all of these layers have to allow something before it actually happens. If ARC-1 is configured read-only, then even a user with a more powerful role still cannot write. If a user has write scope in ARC-1, but the SAP backend authorization is missing, the write still fails.

That is exactly how I want it. ARC-1 should not replace SAP authorization. It should add another control layer in front of it.

Per-user identity matters

This becomes even more interesting once you look at per-user identity. One of the things I wanted very early is that ARC-1 should not force everything through one shared technical SAP user if that can be avoided.

That is why Principal Propagation is such an important part of the architecture for me. If Principal Propagation is active, the MCP user identity can flow through ARC-1 and into SAP, so that the action runs with the real SAP user and the real SAP authorization of that person. I already tested this and it works.

That is important not only because it is cleaner technically. It is important because it fits much better into audit, compliance, and real enterprise authorization models. I do not want the whole architecture to end in “trust this one service account and hope nobody asks too many questions later”. I want the system to be able to say who actually did what.

Audit logging is part of the feature, not an afterthought

The same applies to audit logging. If AI is allowed to read from or write to a real SAP system, then logging is not some optional extra feature. It is part of the basic architecture.

ARC-1 emits structured audit events and can integrate with the BTP Audit Log Service. That means you can log who called which tool, what happened, and in which request context it happened. Especially on BTP, that gives you a much better compliance story than a local MCP server that mostly lives on one laptop.

For normal hobby tooling this might feel like overkill. For SAP it does not. Especially if the recommended target architecture is BTP, it makes sense to also use the established platform services for logging and identity instead of building a parallel side world around them.

Not locked into one client

This point is also important to me personally. There are already many useful prompt files, local plugins, slash commands, and client-specific workflows around SAP and ABAP. I do not think that is wrong. A lot of that work is useful and practical.

But that is still a different architecture. Very often the logic, the access, and the credentials live mainly on one laptop and inside one AI client. For enterprise usage I want the opposite.

I want one secure ADT MCP server that can be used from many clients. That can be Claude, GitHub Copilot, Copilot Studio, IDEs, or later other MCP clients that also support OAuth. In the best case, that can then be combined with Principal Propagation instead of local SAP credentials.

That flexibility matters, because in many companies the default AI developer tooling will not be Claude Code. It will more likely be GitHub Copilot or other centrally managed tools. And I do not want the SAP side of the architecture to depend on one specific AI client. MCP is useful exactly because it decouples those things.

Testing matters more here than for normal dev tooling

I also want to stress the testing part, because for a project like this it matters a lot.

If an MCP server only works in one perfect demo system, then that is not enough. SAP systems are messy. Different releases behave differently. Different endpoints exist or do not exist. BTP ABAP is different again. And error handling around ADT is not always beautiful.

That is why ARC-1 puts a lot of effort into testing. Right now the project has more than 1,300 unit tests, plus integration tests and E2E tests that execute real MCP tool calls against live SAP systems. As a freelancer I obviously do not have access to every possible enterprise landscape, but I do test against real systems. I test against BTP ABAP, the ABAP trial system in Docker, and the older 7.50 trial system.

I also do not test only with one ideal model and one toy example. I try it myself with stronger and weaker models and with workflows that are much closer to reality. That includes things like clean core analysis or creating a full RAP project from nothing, not even a table, up to an activated RAP project you can actually use. A lot of the workflows and feature ideas behind that are also visible in the ARC-1 skills catalog, because those are more or less the kinds of use cases I want to make work reliably.

For me that is also one of the big lessons from working with SAP tooling in general: if you do not test against real systems, you often only test your assumptions.

So yes, this is another ADT MCP server

And that is fine. I do not think ARC-1 needs to exist because every other project is wrong. Quite the opposite. The other projects created the category, pushed the ecosystem forward, and showed there is real interest.

At the same time I think ARC-1 is different enough in architecture and focus that it makes sense right now. It is especially different from the angle of secure defaults, central deployment, layered security, per-user identity, and auditability.

And yes, it may also differentiate itself from the future official SAP approach depending on how that evolves. As of SAP’s November 4, 2025 announcement about the next era of ABAP development, SAP plans an official ABAP MCP server for Q2 2026 together with the ABAP language server and related SDK pieces in VS Code. I think that is good news.

Actually, that is also the point where building yet another ADT MCP server becomes harder to justify long term. If SAP publishes the language server and SDK in a reusable way, then the right move would be to reuse the same foundation that the official SAP MCP server and Eclipse tooling use instead of reimplementing more and more HTTP details on the community side.

If SAP ends up shipping a server with a similar architectural direction, broad system coverage, and the same kind of enterprise features, then there may eventually be no strong reason for ARC-1 to continue. For me that would still be a win.

The point is not that my server must win. The point is that there is clearly a gap today, the community is filling it, and competition is usually good. It helps people choose, it helps ideas spread, and ideally it also helps SAP learn from what the community already built. Until then, people can decide on their own if ARC-1 is useful for them.

A note on ADT APIs and SAP’s new API policy

There is one more point worth separating from the architecture discussion. SAP published a new API policy in April 2026, and some practical implications still need clarification, especially for SAP customers, partners, and community tools that build on top of SAP development APIs.

For ADT, the publicly available material points to a more nuanced situation. SAP provides an official ADT SDK with JavaDoc, and the ADT download page describes it as a public API to implement or integrate your own tools with SAP’s ABAP IDE. There is also an SAP document about creating and consuming RESTful APIs in ADT. This does not imply that every internal /sap/bc/adt endpoint is covered by the same support boundary, but it does show that parts of the ADT tooling and communication model are documented and intended for integration scenarios.

This is also relevant to what SAP wrote in the discussion around the new ABAP Development Tools for VS Code. SAP described the ABAP language server as something like an “ADT SDK 2.0” and mentioned plans to release it as a standalone component after the first VS Code extension release. A standalone release could make the support boundaries clearer for community tools, CLIs, MCP servers, and other integrations. Until more detailed guidance is available, the main point is to track SAP’s policy and documentation closely and adjust implementations when specific activities are clarified as unsupported or not permitted.

Why this matters for the next post

In this post I mainly wanted to explain why ARC-1 exists at all and why it looks the way it does.

The next post is where I want to go deeper into the BTP side, because that is where the architecture becomes much more interesting in practice: XSUAA, Destination Service, Cloud Connector, Principal Propagation, and how this can fit into a real enterprise setup instead of just a developer laptop.

References & links

ABAP and Agentic AI: The Hidden Problem in Real Projects

Wed, 22 Apr 2026 09:00:00 +0200

Series note: This post is part of my AI ABAP development series, where I go from AI development in general, to ABAP-specific problems, and then to ARC-1.

In the first post of this series, I wrote more generally about how I use AI today, why context matters so much, and why I am still not fully convinced by the more maximalist agentic hype.

Here I want to get more concrete. Because SAP development is not one thing, and that matters a lot for AI.

There is a big difference between UI5 or CAP development with AI and ABAP development with AI. If I mix those together, then the whole discussion becomes too vague very quickly.

For me this comes down to three questions:

How does the model get the needed context?
Where does the writing happen?
Who is actually in control of that setup?

I want to answer those questions in this post.

SAP development is not one thing

When people talk about “AI in SAP development”, a lot of very different things get mixed together.

UI5, Fiori, CAP, BTP extensions, ABAP Cloud, ABAP on a shared dev system, Joule in Eclipse, MCP servers, local git workflows, sandbox systems, custom code migration. All of that gets thrown into one big AI bucket.

But these are not the same problem. The reason I want to split this early is simple: some SAP development areas already fit quite naturally into AI assisted workflows, and some really do not.

If I do not separate that clearly, then the discussion becomes too vague very quickly.

Why UI5 and CAP already feel much more natural

For frontend work like UI5, Fiori, CAP, or generally JS and TS based development, AI usage already feels much more normal. The development is usually off stack. You work in local files, use git, open pull requests, run CI/CD pipelines, let tests run, get peer review, and only then move the change further. If AI does something weird, it is annoying, but usually not catastrophic, because there are already good gates in this ideal process.

That is also why GitHub Copilot in VS Code became pretty normal in a lot of companies. If you combine that with good context, for example docs from SAP Help or SAP Docs through MCP, then you can already move quite fast today. I use my own sap-mcp-docs server a lot for exactly that. SAP also moved in that direction with MCP servers for UI5, CAP, and Fiori.

In that environment the three questions above are much easier to answer:

Context comes from local files, documentation, and existing dev tooling.
Writing happens locally, not directly in a shared SAP system.
Control already exists through git, reviews, tests, and pipelines.

So the main question there is often more about workflow quality than about technical possibility.

Why ABAP is structurally harder

In the ABAP world things look different. The two main problems are the architecture and the tooling.

ABAP development is usually on stack. That means if you develop on the dev system, every change is directly applied to that shared system and can affect other developers as well. Even without AI that is already something you have to be careful with. With AI it becomes more sensitive, because a wrong write action is not just a wrong local file edit.

The second problem is tooling. A lot of ABAP developers still use SE80. Eclipse has been there for a long time, but if you were never forced into newer development models like RAP, a lot of people just stayed where they were. And if your main world is still SE80, then there is not really much serious AI support there.

So if I compare UI5 and ABAP, the problem is not only “does the model know ABAP”. The bigger question is in which environment this happens at all, and what happens if the model is wrong.

That is also why I think the SAP Community post The agentic revolution is here, and your ABAP code is the foundation fits quite well here.

The point there is not really that agents replace ABAP. It is more that if agents are going to call into SAP systems, then your ABAP foundation matters even more. Interfaces, CDS views, checks, naming, error handling, package structure, all of that becomes important.

The better and clearer your ABAP foundation is, the more useful and safer the agent layer on top can become, because they use your ABAP code as the foundation for their work.

Model choice still matters, of course. I already wrote two separate posts around ABAP code generation and ABAP understanding, and my practical takeaway is still that strong general models together with better tooling and grounding are currently the better path than hoping one SAP specific model alone solves the problem. But even with a better model, the structural ABAP problem stays the same: on stack writes, shared systems, and weak control do not disappear. Frontier models are just better to handle more complex problems as with complexity comes usually a larger context to handle, and frontier models are usually better at that.

The three questions matter more than the hype

I think this is also why Agentic Engineering Patterns from Simon Willison fits so well here.

What I like there is that “agentic” is not treated like some magical category. It is more a set of working patterns: tools in a loop, tests, boundaries, anti-patterns, habits, and when not to let the loop run too far. For ABAP this matters even more, because the question is not only if an agent can do something, but what kind of loop you actually allow it to run against a real SAP system.

So for every pattern below I want to keep asking the same three questions:

How does the model get context?
Where does writing happen?
Who controls that setup?

Current patterns for AI assisted ABAP development

Lars Hvam wrote a very useful paper on the patterns for using LLMs in ABAP development. You can read more details and see diagrams there.

I like that framing because it avoids the fake discussion of “one right way”. There is not one right way. There are different patterns with different tradeoffs depending on your landsacpe, knowledge, and setup.

1. IDE integrated AI in Eclipse

This is the most obvious option. You stay where you already work and let the built in AI features help with explanations, code suggestions, tests, and smaller implementation tasks. Depending on landscape and setup, that could mean Joule for Developers, GitHub Copilot in Eclipse, or Amazon Q Developer for Eclipse.

Context: Mostly the currently selected SAP object plus what the IDE integration can access or what you add manually.
Writing: Directly to the SAP system.
Control: Mostly on the developer side, not much central boundary around the agent loop itself.

This is easy to adopt as “quick win”, but it does not solve the core architecture problem.

2. VS Code, today mostly with ABAP Remote FS and soon also with SAP’s own extension

This gives a much better AI developer experience because VS Code is simply ahead in that area compared to Eclipse. Today that usually means community tooling like ABAP Remote FS. But SAP’s own ABAP Cloud Extension for VS Code is planned for Q2 2026, so likely around May if that timeline holds. That means ABAP Remote FS is probably more of a bridge than the long term answer, at least for the scenarios SAP will cover first.

The problem stays similar though. If the setup writes back directly through ADT APIs, then the nicer editor experience still does not remove the main risk.

Context: Better local editor experience, but still tied to what the tool can read from the system.
Writing: Still directly to the SAP system.
Control: Still relatively weak if the whole setup sits with the individual developer.

So the nicer developer experience does not remove the main risk.

3. ADT MCP Server

This is where things get really interesting.

With an ADT MCP server the AI does not just see files. It gets structured tools. It can read objects, search code, inspect context, run checks, navigate references, write changes, etc., depending on what the server allows.

This is also currently one of the best ways to solve the context problem.

I already wrote earlier about this direction in Finally: An MCP Server for ABAP, and since then the space has grown a lot. That is also why I keep SAP MCP Servers: The Missing Overview around, because the number of SAP MCP servers and adjacent tools is growing quickly enough that it is easy to lose track.

The AI can say: I have a problem in this class, now get me the class, then maybe read the related table, check another class, search similar code, maybe combine that with SAP documentation from another MCP server like sap-mcp-docs, and build up the context automatically. That is really useful.

Context: Very strong, because tools can gather much richer SAP context such as objects, data, and logs.
Writing: Potentially directly to the SAP system.
Control: Depends entirely on how the MCP server is designed, configured, and deployed.

This is exactly why the MCP path is so interesting and so dangerous at the same time.

It solves a real problem, but it also raises the control question much more sharply. It is also why SAP’s post on Standardizing AI Tool Integration with MCP matters. MCP in SAP is not just some hobby side path anymore. It is becoming part of the real architectural conversation.

4. Sandbox systems

In my opinion this is one of the safest options.

Give the AI a sandbox system that can be isolated, reset, or recreated, and suddenly much more becomes possible without damaging the shared dev system.

Context: Very strong, because the AI can still inspect and work against a real SAP system.
Writing: Direct, but only into an isolated system.
Control: Much better than shared-system direct access, but with infrastructure cost and operational overhead.

This is a very good pattern if you can afford it. The problem is that most teams do not have this luxury.

5. Git or off stack development with abapGit and CI/CD

In many ways this is the cleanest approach.

The AI never writes to the SAP system directly. It writes local files, then git, review, checks, and pipeline steps become the gate.

Context: Depends on what additional read access you give the AI.
Writing: Local first, not directly on the SAP system.
Control: Much stronger, because review and automation become the boundary.

This is how a lot of frontend development already works, and it is much easier to trust.

The problem is that many ABAP teams are simply not there yet. If there is no clear package separation, no git workflow, and no pipeline culture, then introducing this only for AI becomes a bigger transformation project.

6. Hybrid approach

This is the pattern I find currently the most practical long term.

The AI works locally or off stack, but still gets read access to the SAP system through ADT or MCP for context.

That means it can understand the actual system better, but the writing still happens in a gated git flow.

Context: Strong.
Writing: Gated.
Control: Much better than direct write access, while still preserving real system context.

For me this is one of the most promising directions.

Read access already gives a lot of value

One thing I find important here is that AI does not need direct write access to be useful. For many real problems, reading and analysis can already take away maybe 80 percent of the work. If an issue comes in, the first question is usually not “who writes the line of code”, but “where is the actual problem”. If the AI can analyse the system, narrow it down, read code, data and logs, suggest where the bug is, and maybe propose the one line change, then the developer can still do that actual line manually. Or the AI writes the proposed fix and the developer still copy pastes it, reviews it properly, and tests it. That alone is already a lot of support.

And this read access is not only useful for developers who want to code faster. It can also help people working more on architecture, specifications, analysis, testing, and migration. If they can read how the system works, where logic is implemented, how much something is used, or what the dependencies are, then that already helps a lot, for changes, fixes and the transformation from ECC to S/4HANA.

That is also why I do not really buy the simple management idea that you just give everyone Copilot or an Agentic AI coding tool and suddenly everyone codes much faster. That is not the real point.

The bigger question for me is how to help ABAP developers and SAP teams in their daily work with things like:

faster problem analysis
less wasted time searching for the right place
easier access to relevant documentation, logs, and data
faster understanding of old logic
better support while writing specs and tests

An MCP server for documentation, an MCP server for SAP access, and access to more internal documentation can already help a lot here without giving full write access to everything.

What current setups still do not solve

So where is the actual gap today?

For me it is not that AI cannot write ABAP. It can. It is also not that AI has no SAP context at all anymore. That situation is improving a lot through ADT tooling, MCP servers, documentation access, and better models.

The real gap is that context access, write access, and control are tied much more closely together in ABAP than in off stack development, and that becomes an enterprise problem very quickly.

What is often still missing is some combination of proper read-only defaults, operation boundaries, package restrictions, blocking dangerous features like free SQL, per-user identity instead of shared technical access, auditing, and a setup that security, basis, and development can all still trust.

That is also why I am skeptical of setups where powerful ADT MCP servers simply run locally on the laptop of an individual user. If someone can set it up, and usually that is not even that hard, then suddenly you have a very powerful bridge from the model into the SAP system, but without much admin oversight around it. In an enterprise landscape that is not ideal at all.

What an ideal setup would look like

So for me the question is not if agentic ABAP development is possible. It already is.

The more important question is what a setup would need to look like if it should actually work in enterprise reality.

For me that ideal direction is something like this: strong read access to real SAP context, useful structured tools instead of blind file edits, write access that is either gated or at least strongly restricted, central deployment instead of every user doing their own thing locally, clear identity handling, auditability, and enough safety boundaries that basis, security, and development can all live with it.

That does not mean every team needs the exact same architecture. But it does mean the next step cannot just be “give the model more power and hope for the best”.

Why this matters for the next post

The next post is where I want to look at what a more enterprise-ready ADT MCP setup should actually provide if you take those problems seriously from the beginning.

How I Use AI for Development and Why Context Matters

Mon, 20 Apr 2026 20:00:00 +0200

Series note: This post is part of my AI ABAP development series, where I go from AI development in general, to ABAP-specific problems, and then to ARC-1.

When it comes to AI, I do not really think about magic.

I think more about another colleague helping me out.

Sometimes that means architecture. Sometimes implementation. Sometimes testing, review, CI/CD, or deployment.

But this only works with trust, and trust needs communication.

If I do not know something, I ask. If code looks strange, I ask. If tests fail, I ask.

The less I need to ask, the more likely it is because I already gave enough context up front: architecture, documentation, constraints, examples, and what I actually want. Even then I still review the result.

That is why using AI well is a skill you build over time.

My first larger projects with AI were much less smooth than newer ones. Over time I learned that better context, better tooling, and better guardrails lead to much better results. AI can speed things up a lot, but it does not remove engineering judgement.

My workflow changed over the last year

Last year I was mostly just using ChatGPT directly, before tools like Claude Code became more normal. I asked something, copied the generated code into my project, checked if it runs, copied the error back if it failed, and repeated that loop.

The error message was context. The result of trying it out was context. That manual loop slowly improved the output.

What changed over time was not only the model. More and more the AI can get context itself.

Before I had to spoon feed much more manually. Now tools can search, read docs, inspect files, and in some cases get the needed context on their own. For me that is one of the biggest improvements, because the AI does not only answer, it can first understand more.

That is also why I liked How I write software with LLMs by Stavros. Not because I use exactly the same workflow, but because it shows quite well that this is not only about the model. The workflow around the model matters a lot as well.

Context matters more than people first think

A lot of the time the biggest value is not even that the model writes code for me.

Very often it helps with understanding. It can explain a codebase, compare options, write down a plan, summarize documentation, help with tests and refactoring, or point me to the next thing I should check. For a lot of developers that alone is already useful, without going fully agentic.

In many projects the important information is not only in the source code. It is in documentation, issues, diagrams, product docs, logs, dumps, table data, screenshots, pipeline output, and things people in the team just know. If the model only sees one file, it often gives you an answer that sounds nice but misses the actual problem.

That is why I really liked the post Context is the Difference Between Slop and Shipping. I think the core point is right.

If you do not understand the system first, or if the model does not get the right grounding, then you just get plausible looking nonsense faster. It looks like momentum, but often it is just wrong output with confidence.

One of the first places where I really noticed this was UI5, especially with controls like the UI5 Wizard. I had to explain the API again and again, and without that extra context the output was often just wrong. That was one of the first moments where I noticed more clearly that in SAP development good context is not optional.

Especially in SAP I noticed pretty quickly that you need some kind of grounding. You want to be able to say: use this documentation, use this guideline, use this code reference, trust this as the source of truth and do not just invent something.

It still hallucinates sometimes, that does not fully go away, but it becomes less. Especially weaker models benefit a lot from having the right information at the right time.

Why I care so much about tooling around the model

That is also one reason why last year I started building my own MCP server for context. It can search GitHub repositories, SAP Help, and related sources, so I can bring better grounding into the workflow.

For SAP development especially this helped, because so much is not directly visible in one code file. If the model can pull in SAP documentation, guidelines, and related references, it gets pushed much more into the right direction.

I now almost always have that SAP docs setup with me. At the beginning it felt even more important, because the models were weaker and hallucinations were stronger. Today it is a bit better with the stronger frontier models.

I also noticed this with BTP and Cloud Foundry work. There the models can often already use the CLI and public documentation quite well. So the models are improving.

But the more special something gets, the more hidden it is, or the more SAP specific it is, the more important that extra context becomes again.

That is also why I do not find the current AI discussion fully convincing sometimes. People talk a lot about models, but much less about the system around the model. To me, context and tooling matter more in real projects than benchmark discussions alone.

Model quality still matters, but it is not the whole story

I already wrote two separate blog posts about ABAP LLM benchmark results, one more around code generation and one around understanding.

My takeaway there was that strong general models are currently still the more practical choice for me, and that tooling and grounding are often the bigger lever than hoping for one SAP specific model to solve everything by itself.

What also helps a lot is that my MCP SAP docs setup is not only pure API documentation. There are also style guides, DSAG guidelines, and other recommendations in there. These are often not hard rules, but they still push you in a certain direction. So even if I do not know the exact recommendation by heart, I can ask the model to look for guidelines and it gets nudged more automatically towards a better direction.

And context is not only documentation. If I say change this class, then the context is not just that class. It is also the tables that are used, the other classes that are called, similar implementations, internal guidelines, what this system can even do, and what is already there in working code. That broader context improves quality a lot more than just throwing one file at the model.

I am still skeptical of full agentic hype

There is also a very practical spectrum in how much AI help you even want. You can just ask questions about context. You can ask it to find docs and let you read them. You can use it for analysis and planning. Or you can let it implement things more autonomously. That is not one binary choice. It is more a slider, and depending on the project, the team, and the risk, you move that slider differently.

At the same time I am still not sure that going more agentic automatically makes you faster. Pure AI assistance already helps me a lot. But once it becomes more agentic, other things get harder again. The coding itself is very fast, but then you spend more time on plans, instructions, guardrails, review, and correction.

This also matches quite well with the METR study on experienced open-source developers. What I found interesting there is not some simple “AI bad” takeaway, but more the gap between feeling faster and actually being faster.

If less time goes into typing code, but more time goes into prompting, reviewing, waiting, and correcting, then it can still feel fast while the total time says something else. That matches quite well with what I notice myself.

At the same time I also do not want to overcorrect too much into pure skepticism. The post Eight years of wanting, three months of building with AI is a good counterexample. AI helped a lot there, but the first more maximalist agentic approach also created a messy codebase, and things only got better again with tighter ownership and stronger review. That feels much closer to reality than either extreme.

For me there is still a big difference between strong AI assistance and just letting the agent fully take over. Writing the code is now often the easiest part. I spend more time before coding on research, testing, planning, and architecture. And I spend more time after coding on review, rework, manual testing, and documentation.

It is still faster in my opinion, but the time moved.

Process helps, but process is also overhead

This also fits well to How I teach Claude Code to work my way. What I like there is that the focus is not on one magical prompt, but on process. Explore first, think first, plan first, then execute.

I do not use exactly the same process everywhere, but the general idea fits very well to what I learned myself. If you give the AI a process, it usually follows one. If you do not, it drifts more easily. At the same time, process also creates overhead, so it is only worth it when the task is big enough.

That is also why I often want the model to first find a reference before it gives me a strong answer. Search for the SAP documentation. Find the guideline. Show me a similar implementation. Do not just make something up because it sounds right.

Why this gets harder in SAP

Security is also part of that trust question. How much trust do you put in the llm itself, how much in the model provider, and how much in the tools around it? How much security are you willing to give up to move faster? For toy projects people often accept a lot of risk. In enterprise development that looks very different.

In SAP this matters even more, because so much important context is outside the code itself. The actual code change can be very small, but understanding why you need that change can require docs, config, logs, dumps, table entries, business process context, authorizations, and knowledge about how the landscape is set up.

At the same time SAP is also moving. I was pleasantly surprised when SAP released MCP servers for UI5, CAP, and Fiori.

In that world it already feels much more natural, because a lot of that development is off stack anyway. You work locally, use git, run pipelines, get peer review, and if something goes wrong you can usually revert it. That is much easier territory for AI assisted development.

So the interesting question for me is not if AI can help in SAP development. It already can. The more interesting question is where it helps today, where it becomes risky, and why especially ABAP development is still much harder than frontend or CAP development.

In frontend and CAP development, AI can already fit quite naturally into workflows many teams already have. In ABAP, things look very different.

The next post is where I want to look more concrete at that gap: what is already possible today, which patterns exist, and why enterprise guardrails matter much more there.

Ai-Abap-Development-Series on Marian Zeis Blog

Introducing ARC-1: A Secure ADT MCP Server for Enterprise SAP Development

Why ARC-1 had to exist

Central instead of local

Two auth hops matter

Safe by default, not allow all by default

Layered security, not just one switch

Per-user identity matters

Audit logging is part of the feature, not an afterthought

Not locked into one client

Testing matters more here than for normal dev tooling

So yes, this is another ADT MCP server

A note on ADT APIs and SAP’s new API policy

Why this matters for the next post

References & links

ABAP and Agentic AI: The Hidden Problem in Real Projects

SAP development is not one thing

Why UI5 and CAP already feel much more natural

Why ABAP is structurally harder

The three questions matter more than the hype

Current patterns for AI assisted ABAP development

1. IDE integrated AI in Eclipse

2. VS Code, today mostly with ABAP Remote FS and soon also with SAP’s own extension

3. ADT MCP Server

4. Sandbox systems

5. Git or off stack development with abapGit and CI/CD

6. Hybrid approach

Read access already gives a lot of value

What current setups still do not solve

What an ideal setup would look like

Why this matters for the next post

Related posts

How I Use AI for Development and Why Context Matters

My workflow changed over the last year

Context matters more than people first think

Why I care so much about tooling around the model

Model quality still matters, but it is not the whole story

I am still skeptical of full agentic hype

Process helps, but process is also overhead

Why this gets harder in SAP

References & links