Introduction
I’m an SAP functional consultant by role, but I’ve always had the soul of a developer. This is the story of how that instinct — along with a lot of late nights, AI assistance, and a fair share of dead ends — led me to build something I never thought I could.
Where It All Started
I started building ABAP FS v2 (we call it ABAP Copilot internally) sometime around May 2025. Can’t even remember the exact date anymore. Probably should have written it down.
I realized our developers were not entirely happy with Eclipse ADT and I wanted to build something better (jury is still out on that) but I had no idea where to even begin. Then a friend of mine - Ketan Shenoy introduced me to Marcello Urbani’s ABAP Remote Filesystem extension, and something clicked.
One Tool Became Thirty
It started as a single Language Model Tool - object search (took me a while and a lot of research to learn what LM Tools API is). It let Copilot find ABAP objects in SAP directly from the chat. That’s it.
Then I kept getting ideas. One tool became two - then ten - then thirty. All using VS Code’s Language Model Tools API, talking to SAP via ADT.
The whole thing lived in one massive 6000-lines file for a while - classic rapid prototyping. No architecture, no plan. Just kept adding without even thinking about maintenance. I just wanted it to “work”.
The Dark Nights
Then I realized several features that were available in Eclipse ADT (at least the ones people actually used and wanted in VS Code) were missing - embedded GUI, ADT feeds, etc., and I spent a lot of nights adding them one by one. Dark nights indeed.
I also tried a few things that didn’t work out. At one point I tried embedding custom ABAP objects (including code) into a local ChromaDB and querying it with natural language. My laptop (like most) could only run the basic all-MiniLM-L2-v2 embedding model which has a 8K context limit (learnt it the hard way). ABAP objects are generally much bigger than that. Didn’t work. Scrapped it. Not every idea makes it, and that’s fine (I guess?)
The MCP Problem
When I decided to add MCP support, I assumed I’d have to extract the core logic of each tool into separate files and then build two parallel paths — one for the Language Model Tools, and another for MCP. That meant touching every single tool - tools that were already “working”. Forget implementing MCP - even the thought of refactoring the 6000-line monolith was exhausting.
Then I thought - what if I could just wrap the existing Language Model Tools as MCP tools, without duplicating anything? I didn’t even think it was technically possible. Threw it at Copilot. Turns out it was. One path, two interfaces. I still had to refactor, but the scope was nothing like what I originally imagined. If you think my V2 PR was too big and complicated, you should have seen the pre-refactored version!
What Came Together
After months of iteration, here’s what ABAP Copilot became:
• Code search with regex, across the entire SAP system
• Read, edit, create ABAP objects without leaving VS Code
• SQL runner, Mermaid diagrams for code flow
• Dump analysis, transport comparison, cross-system comparison
• Embedded SAP GUI via WebView — still not sure how many people actually use this one
• ABAP Cleaner with one click formatting
• MCP support so non-Copilot users could connect too
• Subagents, heartbeats, and the orchestrator
Conclusion - The Merge, and What It Means
Finally got the code merged into Marcello Urbani’s ABAP Remote Filesystem. It’s on the VS Code Marketplace now. Thanks again Marcello - for ABAP FS and for accepting my mess of a PR!!
Something that started as a personal experiment is out there, being used (hopefully). Not bad for a functional consultant, I guess. Lots of late nights. Lots of AI-assisted coding sessions. Lots of learnings — about tool calling, about what models are actually good (and bad) at, about when to scrap an idea and when to push through.
Now I spend my time staring at the install count on the VS Code Marketplace and the issues page on the repo.
Still evolving.
Bluesky
