ABAP in VS Code and the ABAP MCP Server: What Actually Changes for Us as Developers

For years, “ABAP development” meant one of two things: SE80 or Eclipse with ADT. In 2026 that changed, and I think many of us haven’t fully registered how big the shift is. I don’t mean the AI marketing. I mean the plumbing underneath it. What was released Two things matter most: 1. ABAP development tools for Visual Studio Code. The first release shipped in Q2 2026, initially scoped to ABAP Cloud including SAP Fiori app development, with GitHub Copilot and Amazon Q integrated as AI options. SAP says classic ABAP support in VS Code is also a goal, with more object types arriving over the year. So if you work mostly in classic on-premise ABAP, this is not your daily IDE yet. sap sap 2. The ABAP MCP Server. MCP (Model Context Protocol) is an open standard that lets AI agents talk to tools and systems in a structured way. SAP’s ABAP MCP server exposes ABAP development capabilities over this protocol, so any MCP-capable agent can work with ABAP code and systems. As of Q2 2026, it is generally available for both Eclipse and VS Code. sap sap Why the MCP part is the real story The VS Code extension gets the headlines because the community asked for it loudly. But the MCP server is the bigger architectural change. Until now, AI help for ABAP was mostly whatever SAP built into its own tooling. With MCP, SAP has effectively said: bring your own agent. SAP describes this as an open IDE strategy that lets it draw on third-party AI tools such as GitHub Copilot and Amazon Q. In practice, this means the same agent you use for Python or TypeScript can now read and work with your ABAP system, instead of guessing from pasted code snippets. sap It is also the foundation for SAP’s own migration tooling. SAP calls the MCP server a key technical foundation for its new Custom Code Assistant for S/4HANA transformation. sap The part I’d be careful with Being honest, three things worry me more than they excite me: Plausible-but-wrong code. ABAP has a lot of implicit behavior: authority checks, LUW handling, buffering, locking. An agent can produce code that compiles, passes a quick test, and is still wrong in production. Even SAP acknowledges that AI can generate plausible code with subtle errors, and says it relies on human review plus agent-driven testing. If your team doesn’t have ABAP Unit coverage and ATC checks in place, AI will amplify that gap, not fix it. sap System access. An agent connected to your system is an agent connected to your system. Decide before rollout which systems (DEV only? sandbox?), which users, and which authorizations. Don’t let this get decided by whoever installs the extension first. Business data in prompts. Context makes AI useful, and in SAP, context often means sensitive business data. SAP states that ABAP AI services run inside its compliance frameworks and that customers control what is shared. That covers SAP’s services. Third-party agents connected via MCP are your own governance responsibility. sap What I’d do now Try it in a sandbox or trial system first, ideally on an ABAP Cloud / RAP scenario, since that’s where the VS Code tooling is strongest today. Invest in ABAP Unit and ATC before you invest in agents. Tests are what make AI-generated code reviewable. Write down an access policy for MCP-connected agents, even a one-pager. Keep an eye on the roadmap. SAP planned a second agent focused on clean core transformation for Q3 2026, with more agents and multi-agent orchestration to follow during 2026. sap Bottom line ABAP isn’t being replaced by AI. What’s changing is that ABAP is no longer a closed island in the developer tooling world. That’s good news. But the developers who benefit most will be the ones who already write testable, clean-core code, not the ones hoping the agent will clean up after them. Over to you: Has anyone here connected the ABAP MCP server to an agent in a real project yet? What worked, and where did it go wrong?