Skip to content
Today
Sign in

BuildNot yet confirmed elsewhere1 publisher2 min readPublished

Classic dynpros and Smart Forms keep ABAP teams on Eclipse after VS Code ADT reaches GA

SAP's VS Code ABAP Development Tools are generally available, with 80% object-type parity against Eclipse ADT due by end-2026, a dev.to post says. The post's own list of gaps means most teams will keep Eclipse ADT running beside it.

The Engineer · Build desk

How we use AISend a correction

What happened

  • Claude, Copilot or Amazon Q can connect to the editor over MCP, drawing suggestions from the open files and the selected code.
  • Through the ABAP MCP Server, the editor gives agents tools to read tables, execute RFCs and run syntax checks without leaving VS Code.
  • Business services, service definitions, projection views, metadata extensions and service bindings, the CDS-based OData core, appear in the post without caveats.
  • Classes get basic navigation with limited refactoring, function modules were view-only in early releases, and reports get only basic syntax highlighting.
  • The post lists dynpros and module pools, SAPscript and Smart Forms, BDC and LSMW, legacy BAPI wizards and advanced Web Dynpro as still needing Eclipse.

Why it matters

  • capability General-purpose coding agents can work on ABAP code from a standard editor, using one MCP connection for context, checks and proposed changes.
  • exposure Once a developer accepts an agent's diff, modified objects go into the transport request automatically, so that click is the last manual step before the change sits in a transport.
  • cost Teams with mixed estates carry two IDE setups per developer until at least mid-2027, and longer for screen work the post says may never move.

If we had to defend one design choice at review, it would be the language layer. According to the dev.to post, VS Code ADT runs its language services over the Language Server Protocol, where Eclipse ADT uses a proprietary architecture [10]. The post says the protocol makes outside tools such as MCP servers easier to attach [10]. It also says MCP was part of the design from day one, and it calls Eclipse's version a "retrofitted approach" [11]. We think a published protocol is the right base for agent tooling. The post's list of reasons also includes "future-proofing" [15], a property we have yet to see a test suite check.

Agent proposals arrive as inline suggestions. The developer accepts or rejects each one in a git-style diff view [5]. That view shows code. The same MCP connection also lets an agent execute RFCs and read tables on the connected system [3], and we'd expect those calls to leave nothing in the diff to accept or reject. In our view the permissions on the MCP connection decide what an agent can touch, more than the diff does.

According to the post, SAP has committed to 80% object-type parity with Eclipse ADT by end of 2026 and full parity by mid-2027 [12]. That leaves about six months for the last 20% of object types [16]. The same post says legacy GUI tools such as Screen Painter "may never have direct equivalents in VS Code" [9]. We take "full parity" to mean a count of object types. A team that maintains classic screens could see the target met and still need Eclipse for that work [8].

The post also claims a "significantly lower memory footprint" and faster startup than Eclipse, and calls that critical for containerized development [13]. It publishes no measurements, and it does not quote SAP's roadmap for the parity dates. For the memory claim to hold for a given team, both IDEs would need the same system connections and the same open objects when measured.

The post says the agent workflow is strongest for exploratory coding and for learning unfamiliar codebases [14]. We'd point VS Code ADT at that work and at the CDS service layer, where the post lists no caveats [6]. Eclipse ADT stays installed for the object types the post marks as Eclipse-only [8].

What to watch

  • An SAP-published coverage list or roadmap that confirms or revises the end-2026 and mid-2027 parity dates the post reports.
  • Whether function module editing and advanced class refactoring reach VS Code ADT before end of 2026.
  • Whether the ABAP MCP Server lets administrators switch off RFC execution or table reads per connection.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence30
Adoption
Insufficient
Hype gap+30
Incentives
Insufficient
Confidence30
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    Transport requests can be created and managed without switching to SE09/SE10, with automatic inclusion of modified objects.

    ReportedSupportedSource: dev.to post2 sources— create a free account to open themView cited source
  2. [2]

    SAP ABAP Development Tools for VS Code is generally available in 2026.

    ReportedSupportedSource: dev.to postView cited source
  3. [3]

    VS Code ADT gives direct access to ABAP MCP Server tools from within the editor: read tables, execute RFCs, run syntax checks.

    ReportedSupportedSource: dev.to postView cited source

Sources

1 independent publisher whose own reporting we read for this story.

  1. dev.to

    1 article · October 9, 2026

    ADT for VS Code Changes the ABAP Developer Experience — If You Accept the Scope Limits

Share your take

Let Clarity write the post for you.

Signed-in readers get a short post drafted on this story in the register they choose — narrative, analytical, or a direct position — editable to the last word before it goes anywhere. The share buttons at the top of this story work without an account.

Create a free account to composeSign in

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Entities

Loading related stories