“What is this, in one sentence?”

An AI coding agent for SAP development.

It works on your own SAP system, from your developer's laptop. It asks before it builds and checks before it activates. By default you approve every write; you set how far it can go.

ABAP · RAP · CDS · OData services · Fiori Elements apps · freestyle Fiori apps

“Is this my problem?”

You cannot hire enough SAP developers, so work waits. The backlog, the S/4HANA upgrade, clean core and every new idea queue for the same few people. CSPeach takes the slow parts of the job off every developer you have, so you deliver sooner and put less on hold.

The sequence of real SAP work

The backlog S/4HANA upgrade Clean core New ideas
Your developers every project routes here ⟶ projects wait

“Will it break my system?”

Every change takes the same road: a plan you approve, a snapshot, the write, the checks, the session's transport. If a check fails, CSPeach fixes it and checks again, then stops and asks your developer. Broken code is never activated.

The write road A write starts because you asked. For multi-object work CSPeach lays out a plan you approve, then it snapshots, writes, runs a syntax check, activates, and confirms the object really went active. If a check fails, CSPeach fixes the object and checks again, up to three tries. When it still cannot pass, or the next step is one only a person can do, it stops and says what it needs; you do that step and it carries on. The road sits in the session’s transport, or in the request that already holds the object, and stays on the record. You ask A plan you approve For multi-object work The session’s transport Or the request that already holds the object. On the record with /export audit. Snapshot Before the write Write Syntax check On every write Activate Activation check Reports if it didn’t Passes Broken code is never activated. Fails Fails CSPeach fixes it and checks again Up to three tries Tries again It stops and asks you Says what it needs Still failing, or it needs you You do the step, it carries on. The snapshot from before the write is there if you want to go back.

It works in your development system. A change reaches production through your transports and your release process. Write modes, per system: advisory-only proposes, never writes · approval-gated — the default — asks before each write; in a plan run it asks once, for the plan's exact object list, and anything not on that list still asks (set approvals to per-write for a card before every write) · auto writes within the session, for trusted non-production work. A system tagged production is locked to advisory-only.

“Where does my code go? Which AI is this?”

Your ABAP goes from the laptop straight to your SAP system, over ADT REST. That traffic never passes through CSPeach servers, in any mode. A prompt carries the code the task reads: the objects your developer names, and what CSPeach opens to do that work.

Where your data goes ABAP work goes from your laptop straight to your SAP system over ADT, with nothing in between. In every mode the CSPeach server handles sign-in and serves the signed skills and routing instructions. In managed mode, the default, prompts also go through it to the AI model. Your own model key, with prompts going straight to the model, is a future option and not offered today. The CSPeach server never reaches your SAP system. Our side Your side Sign-in and skills, every mode Prompts, in managed mode Prompts Your own model key: a future option, not offered today. Our server never reaches your SAP Your ABAP goes straight to SAP Over ADT, in every mode. Nothing in between. CSPeach server Sign-in, signed skills, routing AI model Your laptop Runs the cspeach CLI Your SAP system Runs the checks and activation

“Does it know SAP, or does it guess?”

It knows where you are. When it connects it reads your system’s release and ABAP version, and writes code for that system and your own development standards — not generic code. Then your system decides: every write gets a syntax check before it is activated, and ATC and the released-API state are measured on your system too.

Clean-core levels, in order New custom development walks the levels in order. Level A is the default: released interfaces only. Level B is official classic APIs, taken by documented exception when there is no released API, and it costs one line documenting the gap. Level C is SAP internal objects, approved, wrapped behind one Z-interface and watchlisted, and it needs architecture-board approval before the build. Level D is forbidden for new code: the step is never taken. Whether a new D finding stops a transport is a rule for your own release process; CSPeach does not enforce one. NEW CUSTOM DEVELOPMENT · A → B → C. NEVER D. THE GATE · ATC AT TRANSPORT RELEASE NO RELEASED API · ONE LINE DOCUMENTING THE GAP ARCHITECTURE-BOARD APPROVAL NEVER D A The default RELEASED INTERFACES ONLY B By documented exception OFFICIAL CLASSIC APIS C Approved, wrapped, watchlisted ONE Z-INTERFACE D Forbidden for new code NO NEW MODIFICATIONS A RULE FOR YOUR OWN RELEASE PROCESS Each step down needs a reason, written down.

It reads the enhancement package on ECC and the release on S/4HANA, and builds what that release can run: RAP with draft needs S/4HANA 2020 or later, and older systems get the OData route they support. The levels above are the ones /abap-clean-core classifies an object against, worded as the one-page guidelines in our free toolkit. The classification is read-only.

“What does my team do with it on Monday?”

A spec goes in, as a PDF or a Word file, and one command takes it the whole way: the missing questions, the design, the plan and the build. Before anything is built, CSPeach recommends where the app should live — inside SAP or beside it — shows the lines in the spec that decided it, and your developer confirms. The build is ABAP, RAP, CDS, the OData service and the Fiori app, or an app beside the core.

Example from a sample spec

You›/abap-app @customer-credit-review.docx
CSPeachStep 1 of 3 · Finding the gaps in the specI found 4 questions the spec doesn’t answer. 1 must be answered before anyone builds.
CSPeachmust answer When a customer is rejected, should SAP stop new orders, or only show a “credit hold” note?
You›Only show the note. Sales decides.
CSPeachSaved to the spec. Next:
should answer Can a manager overrule a reviewer?
You›No. Only Sarah Davis and Mike Johnson decide.
CSPeachSaved. 2 left, both can wait. Ready for step 2: choosing how to build it.

“We have Joule. We have Copilot. Why this?”

CSPeach sits alongside them rather than replacing them. Copilot finishes lines in the editor; Joule brings SAP's ABAP models to Eclipse and VS Code, where your SAP entitlement covers it. CSPeach takes the ticket: it asks what the spec left out, plans, builds on the system you already have, runs the checks, activates, and leaves the change in the session's transport, with a report.

From ticket to report One track, left to right. A ticket comes in; CSPeach asks what the spec left out, lays out a plan you approve, builds the ABAP, RAP, service and Fiori objects, runs the syntax check and ATC, activates and verifies the result, leaves the change in the session’s transport or in the request that already holds the object, and hands back a report. Ticket The questions no one asked /abap-spec-gap A plan you approve Build ABAP, RAP, services, Fiori Checks Syntax and ATC Activate and verify Into a transport A report It takes the ticket, not the keystroke. One track, from the ticket to the report.

You hold the controls: it works in your development system, not production — write modes per system, and a snapshot before every write. Runs against ECC EHP7 and higher, on-premise S/4HANA, and S/4HANA Cloud Private Edition. Joule facts as of September 2026. Side by side, row by row: cspeach.dev/vs/joule

“How do we get to clean core — and stay there?”

Two jobs. Stop the bleeding: new work starts from the released API, and your own system checks it before anything is activated. Then clean what you have: every custom object counted, classified A to D with the evidence, fixed, and measured again.

New code, stopped at the door Four stages, left to right, for every new change. First the approach is decided before anything is built: the release state of the API is read on the customer’s own system, and the clean-core level A to D is named with the evidence, using slash abap-clean-core. Then the object is built for the release and ABAP version of that system and the customer’s own written standards. Then that system checks it: a syntax check on every write, and activation confirmed rather than assumed, before it is activated; the middle two stages happen on that system. Last, the decision stays defensible: the level, the options rejected and the citations behind them. Under the road, one more check the developer runs on the same system — ATC on the change, with slash abap-atc-fix. On your own system Decided first The released API checked on your system, and the level A to D named /abap-clean-core Built for your release Your release, your ABAP version and your own written standards /abap-rap, /abap-generate Your system checks it Syntax check on every write. Activation confirmed, not assumed. Checked before it is activated. Defensible later The level, the options rejected, and the citations behind them Written down, not recalled. When you ask ATC on the change /abap-atc-fix The cheapest object to clean is the one that went in clean.

/abap-clean-core decides the approach before the build, reading the release state on your system and naming the level. Every write then gets a syntax check on that system, and /abap-atc-fix runs ATC on the change. The levels are worded as the one-page guidelines in our free toolkit word them.

“How do I run a whole programme with many people — and know it is really done?”

Run it as one team project. Every custom object is counted, decided, fixed in someone's lane, and then measured. Management opens one page: every object, who owns it, what is proven.

The upgrade programme, as one team project Five stages left to right. Scope counts every custom object from your system's own inventory with cspeach team discover. Decide has each person record keep, fix, retire or rebuild for their objects with cspeach team decide. Fix gives each developer a lane, where every fix is a claim, with /abap-upgrade-fix. Prove measures each claim with a check run from cspeach team refresh: fix proven, or fix failed the check; this has been proven on a live S/4HANA system. Keep: after go-live, a later check run shows any fix that slipped back, with cspeach team refresh. All five stages are built. Under them, management reads the status page, the workbook and the CSV export, which show the same counts. An upgrade team project, built today Scope Every custom object, counted by your system cspeach team discover Decide Keep, fix, retire or rebuild, one by one cspeach team decide Fix Each developer works a lane; every fix is a claim /abap-upgrade-fix Prove A check run measures it: fix proven, or fix failed the check cspeach team refresh Proven on a live S/4HANA system A fix counts when a check proves it. A claim until a check measures it. Keep After go-live, a later check run shows any fix that slipped back cspeach team refresh What management sees, any day The status page, the workbook and the CSV. The same counts. nothing to fill in

“Security will not approve a connection yet.”

Then start without one. In standalone mode CSPeach has no access to SAP: it writes each object as a file on the laptop, with a numbered guide beside it. Your developer pastes and activates in ADT or SE80, and you can connect a system later.

Standalone now, connected later Standalone mode is the lower road: CSPeach saves every object it produces as a file on your laptop, under a cspeach-out folder with a numbered GUIDE.md beside it, and you or your developer open the file, paste it into ADT or SE80, and activate it in your SAP system yourself. The upper road is what happens once you connect a system later, when CSPeach reads and writes objects in SAP for you. Your laptop Runs the cspeach CLI Your SAP system Later, once you connect CSPeach reads and writes objects in SAP for you. Standalone Files on your laptop One file per object, in cspeach-out, with a numbered GUIDE.md You or your developer Open the file, select all, paste, in ADT or SE80 Paste and activate In your SAP system, by you. No SAP connection. Every task that would change SAP ends with a numbered guide.

Prompts still go to the model, as in “Where does my code go?”. Nothing is installed in SAP, and no SAP credentials are used.

“What is not ready? Who are you?”

Ask us what is next. We tell you plainly what is built, what is planned, and what is not. The full list is on cspeach.dev/security.

Who we are

Cremencing Solutions. Founded 2013. SAP and ERP development is all we do.

For thirteen years we have been the development team other firms bring in for their clients' SAP systems — so you may not know our name, but systems like yours are where we work.

CSPeach is how we work, built into a tool.

You do not have to take our word for it. One week, one real ticket, on your own system.

“Can’t we build this ourselves?”

Wiring an AI model to SAP is the easy part. What takes months is everything around it. Then someone has to keep all of it working as SAP and the models change.

  • Safe writes — A snapshot before every change, a check after every write, every write in the session's transport, or the request that already holds the object, and read-only until you allow a change.
  • Learned on live systems — Many SAP behaviours are built in, so a change that says “activated” is actually checked.
  • Guided runs — Multi-step work, built from 40 skills.
  • Proof — A check that shows a fix held.

In the demo we show it on your kind of system.

“Show me.”

Real sessions on a real SAP system, start to finish; the last two are drawn from live runs. Pick the one closest to your worry.

cspeach — from a spec to a fiori app

From a spec to a Fiori appA one-page functional spec goes in. CSPeach asks what the spec leaves open, lays out every object for one approval, then builds the CDS views, access control, OData service and Fiori Elements app — each write checked and activated.

“What would a first step cost me?”

One week. One real ticket.

Usage is paid from a credit balance, and that balance is the only limit. You need one developer, CSPeach on that developer's laptop, a development system to connect to — or none at all, in standalone mode — and one real ticket from your backlog. Either side can end it at any time.

Bring CSPeach to your team → Read the security page How writes are governed

CSPeach © Cremencing Solutions · Home