The most common misunderstanding about ABAPilot is that it comes with its own chat window you have to adopt. It doesn’t. ABAPilot is an ABAP MCP server — and the point of the Model Context Protocol is that the AI tooling you already use becomes SAP-aware. VS Code with Codex or Copilot, Cursor, Claude Code, Windsurf: if it speaks MCP, it can read your tables, check your syntax and write ABAP against your ECC or on-premise S/4HANA.
And because the assistant runs inside your editor, it also runs inside your process: the same skills, rules and instruction files your team already uses to govern AI-generated code apply to ABAP too. That second part is what this guide is about — because it’s the difference between “AI that writes ABAP” and “AI that writes your ABAP”.
One server, any IDE
The connector installs with one command and one config block. The same server definition works across clients — only the file location changes:
VS Code (Codex, Copilot agent mode) — .vscode/mcp.json, Cursor — .cursor/mcp.json, Claude Code — .mcp.json in the workspace root:
{
"mcpServers": {
"abapilot": {
"command": "npx",
"args": ["-y", "abapilot"],
"env": {
"ABAPILOT_URL": "http://<sap-host>:<port>/sap/bc/ZABAPilot",
"ABAPILOT_USER": "<sap-user>",
"ABAPILOT_PASSWORD": "<sap-password>",
"ABAPILOT_CLIENT": "100"
}
}
}
}Each developer connects with their own SAP credentials, so every call runs under their own authorizations — the same S_TABU_DIS and S_DEVELOP checks as in SAPGUI, audit-logged in your system. No shared technical user, no new identity silo.
The three layers that make generated code follow your standards
Getting AI-generated ABAP to compile is table stakes. Getting it to look like your team wrote it — your naming conventions, your error-handling pattern, your forbidden statements — takes three layers, and they stack:
Layer 1: IDE-side skills and rules
Every modern AI client reads instruction files from the repository: AGENTS.md for Codex, .cursor/rules for Cursor, CLAUDE.md and skills for Claude Code, .github/copilot-instructions.md for Copilot. Teams put their ABAP house rules there — “Z-programs start with ZR_ for reports”, “never SELECT * in loops”, “all messages via our ZCL_MSG wrapper” — and the agent applies them to every generation, in every session, for every developer. Write them once; they version with your repo like any other code.
Layer 2: ABAPilot’s customer rule set
ABAPilot ships with a configurable rule engine for review and generation: a default rule pack (ECC 6.0 safety, performance, S/4HANA readiness) that customers extend or replace with their own JSON rules — down to custom patterns like “every include must carry our copyright header” with its own severity. These rules apply wherever ABAPilot reviews or generates code, regardless of which IDE asked.
Layer 3: The system as judge
Prompts and rules get you most of the way; the last word belongs to the system itself. Generated code goes through a syntax check against your release and your dictionary before anything is written — an ECC 6.0 system rejects 7.5x syntax no matter how confident the model was. And the in-system whitelist decides which operations are reachable at all.
How a real team runs this today
One of our customers — a European group running SAP on-premise — adopted exactly this setup during a 30-day proof of concept. We didn’t start with the software: we started by studying how their developers actually worked — the templates they used, their naming rules, how code moved from requirement to transport. Their conventions became agent skills in the repository, so the AI wrote their ABAP from day one: their naming, their error handling, their documentation templates.
Just as important was the enablement. Developers who had worked in SE80 for over a decade were trained to drive agents from VS Code against their own ECC — with their rules riding along. At the end of the 30 days the team had measured the time saved on their own backlog, and the PoC converted into a license. Not because of a demo: because their own numbers said so.
Why this beats a bundled chat window
Tools that bring their own UI put your team’s AI workflow inside someone else’s product. The MCP approach inverts it: SAP capability comes to the workflow you already govern. Your prompts, your rules files, your review gates, your git history — with SAP data and ABAP operations as tools inside it. When you switch IDE or model next year, the SAP side doesn’t change: same server, same whitelist, same audit log.
FAQ
Which IDEs and AI clients work with ABAPilot?
Any MCP-capable client: VS Code (Codex, Copilot agent mode), Cursor, Claude Code, Claude Desktop, Windsurf and others. The connector is a standard MCP stdio server installed via npx -y abapilot.
Can the AI follow our internal ABAP naming conventions?
Yes — that’s the recommended setup. House conventions live in your repository’s instruction files (AGENTS.md, .cursor/rules, CLAUDE.md) and in ABAPilot’s customer rule set, so every generation follows them regardless of which developer or IDE asked.
What stops non-compliant code from reaching the SAP system?
Three gates: the rules the agent must follow when generating, ABAPilot’s review against your configured rule pack, and a syntax check against your actual system release before any write — plus the in-system whitelist that controls which operations exist at all.
Does each developer need their own SAP user?
Yes, by design. Every call runs under the calling developer’s own SAP authorizations and is audit-logged with their user — the same governance model as SAPGUI.
Should the MCP server run locally per developer or on a central server?
For most teams, local per developer: the connector updates itself via npx, each developer keeps their own SAP credentials and rules, and there is no extra infrastructure to secure. A centralized deployment starts to pay off from roughly 10–15 developers, when central key management and a single upgrade point outweigh the setup cost.
See it running in your IDE
Book a 30-minute live demo → — bring your own VS Code, we bring the SAP system.