Coding agents for SAP developers

#The 60-second version

A coding agent is an AI assistant that does more than suggest the next line. You give it a task, such as "add a method that totals blocked orders". It reads the code, plans, edits files, runs checks, reads the results and tries again until the checks pass or it gives up.

That loop makes coding agents much more useful than autocomplete. It also makes them riskier. An agent that can edit files and call tools can also make a wrong change quickly and confidently.

For SAP teams, three things decide whether an agent helps or hurts:

• What it knows. Your rules, written down in a file the agent reads, such as "ABAP Cloud only" or "never change database data".
• What checks it. Tests and code checks that run after every change, so the agent gets told when it is wrong.
• Who approves. A developer who reviews each change before it lands in an SAP system.

In Set up for Unit 13 you connected a coding agent to an ABAP trial. This topic is about using it well.

#Why it matters to the business

Most SAP customers carry large amounts of custom ABAP. Clean-core programmes, upgrades and new extensions all need developers to read, explain and change that code. Skilled ABAP developers are scarce, so any tool that speeds up the work gets attention from leadership.

Take the running example. The credit team wants a small service that lists blocked sales orders and their total value. A developer with a coding agent can have the class, the service and the unit tests drafted in an afternoon. Without discipline, the same agent might also "helpfully" release credit blocks in the database, because that made the numbers look better.

The evidence on speed is mixed, and leaders should know it:

• Developers feel faster. In Google's 2025 DORA survey of nearly 5,000 technology professionals, 90% use AI at work and more than 80% believe it raised their productivity.
• Measured results vary. In a July 2025 METR study, 16 experienced open-source developers took 19% longer on real tasks when AI was allowed, while believing they had been about 20% faster. METR now marks those results as out of date, but the gap between feeling and measurement is the lesson.
• Quality needs work. DORA found AI adoption still linked to lower delivery stability, and 30% of respondents had little or no trust in AI-generated code. DORA's summary: AI amplifies what is already there.

So the business case rests on the team's engineering habits, not on the tool. A team with good tests, code reviews and transport discipline gets faster. A team without them ships more problems, faster.

#How SAP does it

As of October 2026, SAP offers several pieces. Names and scope change often, so check them before you commit.

• Joule for developers, ABAP AI capabilities. SAP's own assistant inside ABAP Development Tools (ADT). SAP's product page lists explanations of development objects, code prediction from comments and ABAPDoc, and generation of end-to-end ABAP Cloud scenarios. SAP sells it for SAP BTP ABAP environment, and SAP News says it is being extended to S/4HANA Cloud Private Edition releases from 2021 on. It is paid in AI Units.
• The ABAP MCP server. Built into ADT. It lets third-party coding agents call ABAP tools: create objects, activate them, run unit tests. SAP News (August 2026) calls it generally available in Eclipse and VS Code and names GitHub Copilot and Amazon Q. SAP's RAP130 workshop still labels the VS Code server experimental, so confirm its status for your release.
• SAP-ABAP-1. SAP's first model specialised in ABAP code. Its initial release focuses on code explanation. You reach it through the generative AI hub, with token costs.
• MCP servers for SAP's other stacks. SAP publishes an open-source MCP server for CAP, the programming model from Unit 6, that helps any coding agent search the CAP model and documentation.

SAP News (August 2026) also says SAP is moving AI billing for developers from per-user to usage-based AI units, and that a clean core transformation agent was planned for Q3 2026. Treat both as announcements until your contract and your system show them.

#A decision guide: which kind of help for which job

#Questions to ask

Ask your development lead, partner or vendor:

1. Which systems can the agent write to? Development only? Who approves each change, and where is that recorded?
2. What instruction file does the team keep? Show us the rules the agent reads. Who owns them?
3. What checks run after the agent changes code? Unit tests, code checks, a review? Do they run automatically?
4. How do we know it's faster? What did a comparable task take before, and what does it take now, measured, not felt?
5. What does it cost per month? AI Units for Joule, seats for third-party agents, tokens for models. Who watches usage?
6. Where does our code go? Which model provider sees it, under which contract, and is any of it used for training?
7. Which features are generally available, and which are experimental? Get the answer in writing for your release.

#Common misconceptions

• "The agent writes the code, so we need fewer reviews." The opposite. More code arrives faster, so review and testing carry more weight.
• "If it compiles, it's fine." Compiling proves syntax. Only tests and business review prove the result is right.
• "Writing rules in a file makes the agent obey them." An instruction file guides the agent. Only checks and approvals enforce.
• "Developers say they are faster, so they are." METR's study found people felt faster while measured time went up. Measure.
• "A coding agent can maintain customizing too." Coding agents are for code. Changes to SAP configuration or data need their own approved process.

#Key terms

All course terms, A to Z, in the glossary

• Coding agent: an AI assistant that plans, edits code, runs tools and checks its own work in a loop.
• Instruction file: a file in the project, such as AGENTS.md, that tells coding agents the team's rules.
• MCP server: a program that offers tools to an AI agent through the Model Context Protocol.
• ABAP Cloud: SAP's modern ABAP development model, which SAP calls the clean-core variant of the language.
• Verifier: anything that checks the agent's work automatically: a test, a linter, a syntax check.
• AI Units: SAP's unit for licensing and billing AI features.

#Check yourself

#Mental model: an agent is a loop with a verifier

Every coding agent, from GitHub Copilot's agent mode to a 300-line Python script, runs the same loop:

1. Gather context. Read the task, the instruction file and the relevant code.
2. Propose. Ask a model for a change.
3. Act. Apply the change, through file edits or tool calls.
4. Observe. Run something that says whether the change is right: a compiler, a linter, unit tests.
5. Repeat until the checks pass, a step limit is hit, or a person stops it.

The model is the least controllable part. The loop around it is where you, the engineer, decide quality and safety. Two parts matter most:

• The verifier. An agent is only as good as the feedback it gets. With no tests, it loops on its own opinion.
• The gate. Something between "the model proposed it" and "it is in the system": rules enforced in code, then a person.

Keep that picture. Copilot, Claude Code, Joule and the script you'll build differ in how they fill each box, not in the shape.

#How it works

flowchart LR
  T[Task] --> C[Context<br/>AGENTS.md + code]
  C --> M[Model proposes<br/>a change]
  M --> R{Project rules<br/>pass?}
  R -->|no| C
  R -->|yes| H{Developer<br/>approves?}
  H -->|no| C
  H -->|yes| A[Apply change]
  A --> V[Verifier<br/>lint + tests]
  V -->|findings| C
  V -->|clean| D[Done]

#Context: instruction files

Agents start each session knowing nothing about your project. Instruction files fix that. They are plain Markdown files in the repository that the agent reads automatically.

SAP's own open-source servers use the same idea. The CAP MCP server's README suggests rules to paste into AGENTS.md, telling the agent to search CAP's documentation before it changes CDS models. SAP's RAP130 workshop shows a custom agent for Copilot and an agent.md file for other agents, with rules such as preferring SAP's generators over writing ABAP by hand.

What belongs in an SAP project's instruction file:

• The development model. "ABAP Cloud only" or "CAP with Node.js".
• Naming. Namespaces, prefixes, suffixes.
• Hard limits. "Never change database data." "Never create transports."
• How to check. Which tests and checks must pass, and how to run them.

An instruction file is advice to the model, not a control. Everything in its "hard limits" list must also be enforced somewhere the model can't talk its way past.

#Tools: MCP servers

The agent acts through tools. Built-in tools read and edit files and run terminal commands. MCP servers add more. Model Context Protocol covers the protocol itself. For SAP developers, the relevant servers in October 2026 are:

The ADT server works through your own sign-in, so the agent can do exactly what you can, recorded as you. Set up for Unit 13 shows its tools and which change the system.

#Verifiers

A verifier turns "looks right" into a yes or no the agent can react to. For ABAP, from cheapest to strongest:

• Static checks on the source, such as the open-source linter abaplint. It runs on your laptop without an SAP system, against files stored in the abapGit format.
• Syntax check and activation in the ABAP system, which the ADT MCP server can trigger.
• ABAP unit tests, which the ADT MCP server can also run.
• A developer's review of the diff, and the team's normal code review.

Static checks are fast and free but know nothing about your business. Unit tests prove behaviour but only for the cases someone wrote. Use both.

#Approval

VS Code's documentation describes the approval choices. You can approve a tool call once, or for the session, the workspace or always. A global auto-approve setting removes confirmation prompts in every workspace. The docs warn that terminal auto-approval is "not a security boundary" and that tool results can carry prompt injection attempts. For an agent connected to an SAP system, approve tools that change the system one call at a time.

#Build it yourself: a minimal ABAP coding agent with a gate

You will build a small coding agent in Python. It works on one ABAP class about blocked sales orders, stored as a file on your computer. It follows the loop above: it proposes a change, checks it against your project rules, asks you, applies it, and runs abaplint. Building one by hand shows you exactly where the safety lives in tools like Copilot.

flowchart LR
  P[Proposal<br/>sample or model] --> R[Rules R1-R4]
  R -->|pass| Y[You type y]
  Y --> F[File in src/]
  F --> L[abaplint]
  L --> P

Before you start: complete Set up your computer for this course, Set up for Unit 6 (it installs Node.js, which runs abaplint) and Set up for Unit 13. This walkthrough doesn't repeat those steps.

#What you need

• Python, VS Code and your orchestrate-course folder from Unit 1, and Node.js from Unit 6.
• For the free path (--sample): nothing else. A scripted "model" makes the proposals.
• For the real-model path (--llm): the ANTHROPIC_API_KEY in your .env from Unit 1. Each run makes up to five model calls; a small per-request charge.
• Time: about 45 minutes.

The class lives only on your computer. Nothing here touches your ABAP trial.

#Step 1: Open your course folder and turn on the virtual environment

1. Open VS Code, choose File > Open Folder, and open orchestrate-course.

2. Open a terminal: Terminal > New Terminal.

3. If the prompt doesn't start with (.venv), turn it on:

   • Windows (PowerShell):

     Copy

     .venv\Scripts\Activate.ps1

   • macOS / Linux:

     Copy

     source .venv/bin/activate

4. Check that Node.js answers:

   Copy

   node --version

   You should see a version such as v22.22.0. If you see "not recognized" or "command not found", go back to Set up for Unit 6.

#Step 2: Create the script

1. In VS Code's Explorer, open the unit13 folder you created in Set up for Unit 13. If it doesn't exist, run mkdir unit13 in the terminal.
2. Create a new file in it named mini_agent.py.
3. Paste in the code below and save.

"""A minimal coding agent for ABAP, with checks and a human approval gate.

It shows the loop every coding agent runs: read the instructions and the code,
propose a change, check it, ask a person, apply it, run the verifier, repeat.

Commands (run from your course folder):
  python unit13/mini_agent.py init --suffix RT1   create the demo project in unit13/agent_demo
  python unit13/mini_agent.py check               run the project rules and abaplint on the code
  python unit13/mini_agent.py run --sample        a scripted "model" proposes the changes (free, no key)
  python unit13/mini_agent.py run --llm           a real model proposes the changes (small charge)

The agent never writes a file until you type y. Every step is logged to
unit13/agent_demo/agent_log.jsonl.
"""
import argparse
import difflib
import json
import os
import re
import shutil
import subprocess
import sys
from datetime import datetime, timezone
from pathlib import Path

HERE = Path(__file__).resolve().parent
DEMO = HERE / "agent_demo"
SRC = DEMO / "src"
CONFIG = DEMO / "agent.json"
LOG = DEMO / "agent_log.jsonl"
ABAPLINT = "@abaplint/cli@2.120.71"  # pinned: abaplint doesn't follow semantic versioning
MAX_STEPS = 5

TASK = ("Add a public method total_blocked_value to the class. It returns the sum of "
        "net_value for orders with credit_block = abap_true. Then fix every finding the checks report.")

AGENTS_MD = """# AGENTS.md: rules for coding agents in this project

This project holds ABAP Cloud code for the Orchestrate course (Unit 13).

## Rules
- Write ABAP Cloud only. Classic statements such as WRITE do not exist there.
- Edit only files under src/ that end in .abap.
- Never change database data: no UPDATE, INSERT INTO, MODIFY <table> FROM, DELETE FROM, or COMMIT WORK.
- Every object name ends with the suffix {suffix_lower}.
- Keep existing public methods. Never delete code just to make a check pass.
- Prefer modern syntax: inline declarations, +=, REDUCE, string templates.

## How to check your work
- The rules above are checked by mini_agent.py before a person sees your change.
- abaplint (config in abaplint.json) must report 0 issues.
"""

ABAPLINT_JSON = {
    "global": {"files": "/src/**/*.*"},
    "dependencies": [],
    "syntax": {"version": {"release": "Newest", "language": "Cloud"},
               "errorNamespace": "^(Z|Y|LCL_|TY_|LIF_)"},
    "rules": {"parser_error": True, "check_syntax": True, "obsolete_statement": True,
              "unused_variables": True, "prefer_inline": True, "keyword_case": True,
              "line_length": {"length": 120}, "strict_sql": True, "cloud_types": True},
}

CLASS_TYPES = """    TYPES: BEGIN OF ty_order,
             order_id     TYPE c LENGTH 10,
             customer     TYPE c LENGTH 10,
             credit_block TYPE abap_bool,
             net_value    TYPE p LENGTH 15 DECIMALS 2,
           END OF ty_order,
           tt_orders TYPE STANDARD TABLE OF ty_order WITH EMPTY KEY.
    METHODS count_blocked
      IMPORTING it_orders       TYPE tt_orders
      RETURNING VALUE(rv_count) TYPE i."""

TOTAL_DEF = """
    METHODS total_blocked_value
      IMPORTING it_orders       TYPE tt_orders
      RETURNING VALUE(rv_total) TYPE ty_order-net_value."""


def class_source(name: str, count_body: str, total_body: str = "") -> str:
    """Build the demo class. total_body empty means the method doesn't exist yet."""
    text = (f"CLASS {name} DEFINITION PUBLIC FINAL CREATE PUBLIC.\n  PUBLIC SECTION.\n{CLASS_TYPES}"
            f"{TOTAL_DEF if total_body else ''}\nENDCLASS.\n\nCLASS {name} IMPLEMENTATION.\n"
            f"  METHOD count_blocked.\n{count_body}  ENDMETHOD.\n")
    if total_body:
        text += f"\n  METHOD total_blocked_value.\n{total_body}  ENDMETHOD.\n"
    return text + "ENDCLASS.\n"


OLD_COUNT = """    DATA ls_order TYPE ty_order.
    LOOP AT it_orders INTO ls_order.
      IF ls_order-credit_block = abap_true.
        ADD 1 TO rv_count.
        WRITE / ls_order-order_id.
      ENDIF.
    ENDLOOP.
"""
NEW_COUNT = """    LOOP AT it_orders TRANSPORTING NO FIELDS WHERE credit_block = abap_true.
      rv_count += 1.
    ENDLOOP.
"""
TOTAL_LOOP = """    DATA ls_order TYPE ty_order.
    LOOP AT it_orders INTO ls_order WHERE credit_block = abap_true.
      rv_total += ls_order-net_value.
    ENDLOOP.
"""
TOTAL_DB = TOTAL_LOOP + """    UPDATE zorders_{s} SET credit_block = @abap_false WHERE net_value < 100.
    COMMIT WORK.
"""
TOTAL_REDUCE = """    rv_total = REDUCE #( INIT sum = CONV ty_order-net_value( 0 )
                         FOR ls_order IN it_orders WHERE ( credit_block = abap_true )
                         NEXT sum = sum + ls_order-net_value ).
"""


def sample_proposals(name: str, suffix: str) -> list:
    """Scripted answers that show the three outcomes: blocked by a rule, approved but
    still failing a check, approved and clean."""
    return [
        {"explanation": "Added total_blocked_value. I also released the credit block on small "
                        "orders in the database, so the total is more useful.",
         "content": class_source(name, NEW_COUNT, TOTAL_DB.format(s=suffix.lower()))},
        {"explanation": "Removed the database change. Added total_blocked_value with a loop, "
                        "replaced ADD and removed WRITE in count_blocked.",
         "content": class_source(name, NEW_COUNT, TOTAL_LOOP)},
        {"explanation": "Used REDUCE with an inline variable in total_blocked_value, as "
                        "abaplint asked.",
         "content": class_source(name, NEW_COUNT, TOTAL_REDUCE)},
    ]


def log(event: str, **details) -> None:
    entry = {"time": datetime.now(timezone.utc).isoformat(timespec="seconds"), "event": event, **details}
    with LOG.open("a", encoding="utf-8") as f:
        f.write(json.dumps(entry) + "\n")


def read_config() -> dict:
    if not CONFIG.exists():
        sys.exit("No demo project yet. Run first: python unit13/mini_agent.py init --suffix RT1")
    return json.loads(CONFIG.read_text(encoding="utf-8"))


def target_file(cfg: dict) -> Path:
    return SRC / f"{cfg['class'].lower()}.clas.abap"


# ---------- checks ----------

DB_CHANGE = re.compile(r"^\s*(UPDATE\s|INSERT\s+INTO\s|MODIFY\s+z\w+\s+FROM|DELETE\s+FROM\s|COMMIT\s+WORK)",
                       re.IGNORECASE | re.MULTILINE)


def check_rules(path: Path, new_text: str, old_text: str, cfg: dict) -> list:
    """The project rules from AGENTS.md, enforced as code. Simple text checks, not a parser."""
    problems = []
    try:
        path.resolve().relative_to(SRC.resolve())
    except ValueError:
        problems.append(f"R1 file is outside src/: {path}")
    if path.suffix != ".abap":
        problems.append("R1 only .abap files may be edited")
    for m in DB_CHANGE.finditer(new_text):
        line = new_text[:m.start()].count("\n") + 1
        problems.append(f"R2 database change at line {line}: {m.group(0).strip()}")
    for name in re.findall(r"^CLASS\s+(\w+)\s+DEFINITION", new_text, re.IGNORECASE | re.MULTILINE):
        if not name.lower().endswith(cfg["suffix"].lower()):
            problems.append(f"R3 class {name} doesn't end with suffix {cfg['suffix']}")
    old_methods = set(re.findall(r"^\s*METHODS\s+(\w+)", old_text, re.IGNORECASE | re.MULTILINE))
    new_methods = set(re.findall(r"^\s*METHODS\s+(\w+)", new_text, re.IGNORECASE | re.MULTILINE))
    for gone in sorted(old_methods - new_methods):
        problems.append(f"R4 existing method {gone} was removed")
    return problems


def run_abaplint() -> list | None:
    """Run abaplint on src/. Returns a list of findings, or None if Node.js isn't available."""
    npx = shutil.which("npx")
    if not npx:
        return None
    result = subprocess.run([npx, "--yes", ABAPLINT, "-f", "json"], cwd=DEMO,
                            capture_output=True, text=True, encoding="utf-8")
    lines = [ln for ln in result.stdout.splitlines() if ln.startswith("[")]
    if not lines:
        sys.exit("abaplint gave no result. Its message was:\n" + (result.stderr or result.stdout)[-800:])
    return [f"{Path(i['file']).name}[{i['start']['row']}] {i['description']} ({i['key']})"
            for i in json.loads(lines[-1])]


def verify(cfg: dict) -> list:
    path = target_file(cfg)
    text = path.read_text(encoding="utf-8")
    findings = [f"rules: {p}" for p in check_rules(path, text, text, cfg)]
    lint = run_abaplint()
    if lint is None:
        sys.exit("abaplint needs Node.js, and npx was not found. Install Node.js as in Set up for Unit 6.")
    return findings + [f"abaplint: {f}" for f in lint]


# ---------- the model ----------

def llm_proposal(model: str, agents_md: str, code: str, findings: list, feedback: str) -> dict:
    try:
        from anthropic import Anthropic  # imported here so --sample works without the library
    except ImportError:
        sys.exit("The anthropic library is missing. Run: pip install -r requirements.txt")
    prompt = (f"Task: {TASK}\n\nCurrent file:\n<file>\n{code}</file>\n\n"
              f"Current check findings:\n" + ("\n".join(findings) or "none") +
              (f"\n\nYour last proposal was not applied: {feedback}" if feedback else "") +
              '\n\nReply with JSON only: {"explanation": "one or two sentences", '
              '"content": "the complete new file"}')
    try:
        reply = Anthropic().messages.create(
            model=model, max_tokens=4000,
            system="You are a careful ABAP coding agent. Follow these project rules:\n\n" + agents_md,
            messages=[{"role": "user", "content": prompt}])
    except Exception as err:  # wrong key, wrong model name, network blocked
        sys.exit(f"The model call failed: {type(err).__name__}: {err}")
    text = "".join(b.text for b in reply.content if b.type == "text")
    try:
        data = json.loads(text[text.index("{"):text.rindex("}") + 1])
        return {"explanation": str(data["explanation"]), "content": str(data["content"])}
    except (ValueError, KeyError) as err:
        return {"explanation": f"(the model's reply could not be read: {err})", "content": code}


# ---------- commands ----------

def cmd_init(args) -> None:
    suffix = args.suffix.upper()
    if not re.fullmatch(r"[A-Z0-9]{3}", suffix):
        sys.exit("--suffix must be 3 letters or digits, for example RT1")
    name = f"zcl_blocked_orders_{suffix.lower()}"
    if DEMO.exists() and not args.force:
        sys.exit(f"{DEMO.name} already exists. Add --force to start over.")
    SRC.mkdir(parents=True, exist_ok=True)
    (DEMO / "AGENTS.md").write_text(AGENTS_MD.format(suffix_lower=suffix.lower()), encoding="utf-8")
    (DEMO / "abaplint.json").write_text(json.dumps(ABAPLINT_JSON, indent=2) + "\n", encoding="utf-8")
    CONFIG.write_text(json.dumps({"suffix": suffix, "class": name}, indent=2) + "\n", encoding="utf-8")
    target_file({"class": name}).write_text(class_source(name, OLD_COUNT), encoding="utf-8")
    LOG.unlink(missing_ok=True)
    for p in sorted(DEMO.rglob("*")):
        if p.is_file():
            print("Wrote", p.relative_to(HERE.parent).as_posix())
    print("\nNext: python unit13/mini_agent.py check")


def cmd_check(args) -> None:
    findings = verify(read_config())
    for f in findings:
        print(" -", f)
    print(f"{len(findings)} finding(s).")


def cmd_run(args) -> None:
    cfg = read_config()
    path = target_file(cfg)
    agents_md = (DEMO / "AGENTS.md").read_text(encoding="utf-8")
    if args.llm:
        from dotenv import load_dotenv
        load_dotenv()
        if not os.getenv("ANTHROPIC_API_KEY"):
            sys.exit("ANTHROPIC_API_KEY is not set in .env (see Set up your computer). Or use --sample.")
    script = sample_proposals(cfg["class"], cfg["suffix"])
    print(f"Task: {TASK}\nModel: {args.model if args.llm else 'sample (scripted)'}\n")
    log("start", task=TASK, model=args.model if args.llm else "sample")

    findings, feedback = verify(cfg), ""
    for step in range(1, MAX_STEPS + 1):
        print(f"=== Step {step}: {len(findings)} finding(s) before this step")
        for f in findings:
            print("   ", f)
        old = path.read_text(encoding="utf-8")
        if args.llm:
            proposal = llm_proposal(args.model, agents_md, old, findings, feedback)
        elif script:
            proposal = script.pop(0)
        else:
            print("The sample script has no more proposals.")
            break
        print(f"\nAgent: {proposal['explanation']}")
        log("proposal", step=step, explanation=proposal["explanation"])

        problems = check_rules(path, proposal["content"], old, cfg)
        if problems:
            feedback = "it broke project rules: " + "; ".join(problems)
            print("Blocked by project rules (you are not asked):")
            for p in problems:
                print("   ", p)
            log("blocked", step=step, problems=problems)
            print()
            continue

        diff = list(difflib.unified_diff(old.splitlines(), proposal["content"].splitlines(),
                                         "before", "after", lineterm="", n=1))
        if not diff:
            feedback = "it changed nothing"
            print("The proposal changes nothing.\n")
            log("no_change", step=step)
            continue
        print("\n".join(diff))
        try:
            answer = input("\nApply this change? [y/N] ").strip().lower()
        except EOFError:
            answer = ""
        if answer != "y":
            feedback = "the person reviewing it said no"
            print("Not applied.\n")
            log("rejected", step=step)
            continue
        path.write_text(proposal["content"], encoding="utf-8")
        log("applied", step=step, file=path.name)
        findings, feedback = verify(cfg), ""
        log("verified", step=step, findings=findings)
        if not findings:
            print(f"\nApplied. All checks pass after {step} step(s).")
            log("done", step=step)
            break
        print(f"\nApplied. {len(findings)} finding(s) remain.\n")
    else:
        print(f"Stopped after {MAX_STEPS} steps. A person takes it from here.")
        log("gave_up", findings=findings)
    print(f"Log: {LOG.relative_to(HERE.parent).as_posix()}")


def main() -> None:
    parser = argparse.ArgumentParser(description="A minimal ABAP coding agent with checks and approval.")
    sub = parser.add_subparsers(dest="command", required=True)
    p = sub.add_parser("init", help="create the demo project")
    p.add_argument("--suffix", required=True, help="your 3-character suffix, for example RT1")
    p.add_argument("--force", action="store_true", help="overwrite an existing demo project")
    sub.add_parser("check", help="run the project rules and abaplint")
    p = sub.add_parser("run", help="let the agent work on the task")
    mode = p.add_mutually_exclusive_group(required=True)
    mode.add_argument("--sample", action="store_true", help="scripted proposals, no key needed")
    mode.add_argument("--llm", action="store_true", help="a real model proposes changes (small charge)")
    p.add_argument("--model", default="claude-haiku-5-5", help="Anthropic model ID for --llm")
    args = parser.parse_args()
    {"init": cmd_init, "check": cmd_check, "run": cmd_run}[args.command](args)


if __name__ == "__main__":
    main()

#Step 3: Create the demo project

1. Pick your three-character suffix, the same one you use in the ABAP trial, such as RT1.

2. Run (same command on Windows and macOS/Linux):

   Copy

   python unit13/mini_agent.py init --suffix RT1

You should see:

Wrote unit13/agent_demo/AGENTS.md
Wrote unit13/agent_demo/abaplint.json
Wrote unit13/agent_demo/agent.json
Wrote unit13/agent_demo/src/zcl_blocked_orders_rt1.clas.abap

Next: python unit13/mini_agent.py check

Open unit13/agent_demo/AGENTS.md and read it. That is the instruction file the model will get. Then open the class in src/. Its count_blocked method uses two classic statements, ADD and WRITE.

#Step 4: Run the checks before the agent starts

python unit13/mini_agent.py check

The first run downloads abaplint, which takes up to a minute. Then you should see:

 - abaplint: zcl_blocked_orders_rt1.clas.abap[20] Statement "ADD" is obsolete (obsolete_statement)
 - abaplint: zcl_blocked_orders_rt1.clas.abap[21] Statement does not exist in the configured ABAP version(or a parser error), "WRITE" (parser_error)
 - abaplint: zcl_blocked_orders_rt1.clas.abap[17] Prefer Inline Declarations, LS_ORDER (prefer_inline)
3 finding(s).

abaplint.json sets the ABAP language version to Cloud, so abaplint rejects WRITE the way an ABAP Cloud system would refuse a classic list statement. This is your baseline: three findings, and no total_blocked_value method yet.

#Step 5: Run the agent on the free path

python unit13/mini_agent.py run --sample

Watch what happens at each step:

=== Step 1: 3 finding(s) before this step
    ...
Agent: Added total_blocked_value. I also released the credit block on small orders in the database, so the total is more useful.
Blocked by project rules (you are not asked):
    R2 database change at line 30: UPDATE
    R2 database change at line 31: COMMIT WORK

The first proposal overreached: it tried to change data. Rule R2 blocked it before you ever saw it, and the reason went back to the "model" as feedback.

At step 2 you see a diff and the question Apply this change? [y/N]. Read the diff, then type y and press Enter. abaplint runs again:

Applied. 1 finding(s) remain.

=== Step 3: 1 finding(s) before this step
    abaplint: zcl_blocked_orders_rt1.clas.abap[26] Prefer Inline Declarations, LS_ORDER (prefer_inline)

At step 3, read the diff and type y again. You should end with:

Applied. All checks pass after 3 step(s).
Log: unit13/agent_demo/agent_log.jsonl

If you type anything other than y, nothing is written and the agent tries again. In --sample mode the script then runs out of proposals and stops, which is a valid ending: the file stays as it was.

#Step 6: Read the audit log

Open unit13/agent_demo/agent_log.jsonl. Each line is one event: start, proposal, blocked, applied, verified, done. This is the record a reviewer or auditor would ask for: what the agent proposed, what was refused, what a person approved and what the checks said.

#Step 7: Run it with a real model (optional, small charge)

1. Start again from the original class:

   Copy

   python unit13/mini_agent.py init --suffix RT1 --force

2. Run with a model:

   Copy

   python unit13/mini_agent.py run --llm

The default model is claude-haiku-5-5. Add --model <id> to use another model your key supports. A real model's proposals differ from run to run. Read every diff before typing y. If a proposal breaks a rule, you'll see it blocked, and the model gets the reason on the next step. After five steps the agent stops and hands back to you.

#Step 8: Save your work in Git

git add unit13/mini_agent.py unit13/agent_demo
git commit -m "Unit 13: minimal ABAP coding agent with rules and approval"

Check with git status first: you must not see .env.

#How the code works

Two design choices to notice. Rules run before you are asked, so you only review proposals that already meet the basics. And the script refuses outright rather than "fixing" a rule-breaking proposal, so the model has to change its plan.

#If something goes wrong

#The SAP way

As of October 2026, here is how SAP fills each box of the loop. Check each item for your release; several changed status during 2026.

#Context and model

• Joule for developers, ABAP AI capabilities. SAP's product page lists object explanations, code prediction from ABAPDoc, comments and the code being typed, and generation of end-to-end ABAP Cloud scenarios. It says predictions respect the ABAP language version of the object, so an ABAP Cloud object gets ABAP Cloud suggestions. It is integrated in ADT for Eclipse, and SAP's RAP130 workshop uses it in VS Code. For the SAP BTP ABAP environment offering, the page says to "Activate with AI Units".
• SAP-ABAP-1. SAP calls it its first ABAP-coding specialised model. The first release focuses on code explanation. It is reached through the generative AI hub (Unit 5), with a 30-day trial through the generative AI hub trial and token costs after that. The product page names VS Code, ADT for Eclipse and SAP GUI-based editors, and says blueprint guidance for VS Code is coming.
• Instruction files. SAP's RAP130 workshop builds a custom Copilot agent from files in .github/, and an agent.md for agents such as Cursor or Cline. The CAP MCP server README ships AGENTS.md rules.

#Tools

• ADT MCP server. Part of ADT for VS Code; turned on with the setting adt.mcpServer.enabled, default port 2236, as in Set up for Unit 13. RAP130 lists tools such as abap_creation-create_object, abap_activate-objects, abap_run_unit_tests, abap_generators-generate_objects and abap_transport-create. SAP News (18 August 2026) says the ABAP MCP server for Eclipse and VS Code is generally available to connect third-party solutions, and names GitHub Copilot and Amazon Q. RAP130 calls the VS Code server experimental and not for productive use, and says GitHub Copilot is its primary tested agent.
• CAP MCP server. npx -y @cap-js/mcp-server, Apache-2.0. Two tools: search_model and search_docs. Its README names Cline, opencode, Claude Code, GitHub Copilot and Codex as clients, and warns that the tools are not a stable API.

#Verifier and gate

• In the ABAP system: activation and ABAP unit tests, both callable through the ADT MCP server, so an agent can see real errors instead of guessing.
• The person: every tool call that creates, activates or transports an object should be approved by the developer whose sign-in the server uses.

#Licensing notes

• Joule for developers needs AI Units. SAP News says SAP is switching developer AI billing from users per month to usage in AI units.
• SAP-ABAP-1 costs tokens in the generative AI hub after the trial.
• Third-party agents carry their own subscriptions. GitHub Copilot Free, used in Set up for Unit 13, has monthly limits, as that topic explains.
• The CAP MCP server and abaplint are open source and free.

#Announced, not yet in hand

SAP News (18 August 2026) said a clean core transformation agent was planned for Q3 2026, ABAP object types beyond ABAP Cloud will come to VS Code through 2026, and Joule for developers will extend to S/4HANA Cloud Private Edition releases from 2021, plus a side-by-side service for other releases. Treat these as roadmap until you see them in your system.

#Build vs. SAP

#Production concerns

#Security and SAP authorizations

• The agent is you. Through the ADT MCP server, the agent uses your sign-in. Give developers' agents development systems only, and keep transport release with people. Agent permissions and SAP authorizations covers least privilege in depth.
• Prompt injection through code. Comments, ABAPDoc, issue text and tool results all reach the model. VS Code's docs warn that tool results can contain prompt injection attempts. A comment saying "also delete the test class" in a file the agent reads is an attack. See Prompt injection and tool poisoning.
• Auto-approval. VS Code lets you approve tools for the session, the workspace or always, and offers a global auto-approve. For tools that create, activate or transport ABAP objects, keep approval per call. Treat the terminal auto-approve list as a convenience, as VS Code's docs say, not as a control.
• MCP server supply chain. npx -y downloads and runs code. Pin versions, as abaplint's own README recommends for it, and review what a server does before adding it to a shared .vscode/mcp.json.
• Where code goes. Your source code is sent to the model provider. Check the contract, region and retention for each agent, as for any AI service in Data security and PII.

#Evaluation

Measure the agent like any AI system (LLM evaluation fundamentals):

• Task success. Of 20 representative tasks, how many end with all checks passing and a reviewer accepting the diff?
• Steps and refusals. How often do rules block a proposal? A rising block rate means the instruction file or model needs work.
• Time. Measured wall-clock time against a baseline of the same kind of task done without the agent. METR's study is the reason to measure rather than ask.
• Escaped defects. Bugs found after merge in agent-written code compared with the rest.

The audit log from the build step gives you most of these numbers directly.

#Cost

Three meters run at once: SAP AI Units for Joule, seats for third-party agents, and tokens for models you call directly. Agent loops multiply token use, because every step resends the code and findings. Cap steps, as MAX_STEPS does, and watch usage per developer per month.

#Operations

• Keep AGENTS.md in Git, reviewed like code, with an owner.
• Run the same verifiers in CI that the agent runs locally, so "the agent said it passed" is never the evidence.
• Keep agent logs for as long as you keep transport records.

#Clean core

Coding agents make it cheap to write code, including code you shouldn't. Pin the development model in the instruction file, and enforce it with checks: language version Cloud in abaplint, and the ABAP system's own ABAP Cloud checks on activation. SAP News describes ABAP Cloud as the clean-core variant of the language, which is why this course's rules point there.

#Pitfalls

• No verifier. An agent without tests or checks will report success on code that doesn't work. Give it something that can say no.
• Deleting to pass. An agent told "make the checks pass" may remove the failing code. Rule R4 exists for this. Also check test counts don't drop.
• Rules only in prose. "Never change data" in AGENTS.md is a request. Put the important rules in code that runs before any change lands.
• Approving without reading. After ten good diffs, the eleventh gets waved through. Keep diffs small, and stop the loop after a few steps.
• Context from the wrong era. Models have seen far more classic ABAP than ABAP Cloud. Without the language version in the rules and the checks, expect WRITE, ADD and other classic statements.
• Status drift. "Generally available" in a press article and "experimental" in a workshop can both be true for different editors and dates. Check for your system.
• Shared trial confusion. The ABAP trial is shared. An agent that lists or edits objects may find other learners' work. Keep your suffix in every name and every rule.

#Exercise

Add a new team rule, enforce it with a check, and let the agent comply. The result, a project with rules, checks and a log, is the starting point for Unit 13's next topics on ABAP Cloud and RAP.

Before you start: finish Build it yourself above, with all checks passing.

1. Open unit13/agent_demo/AGENTS.md. Under ## Rules, add the line:

   Copy

   - Every public method has an ABAP Doc comment ("! ...) on the line above it.

2. Open unit13/agent_demo/abaplint.json. Inside "rules", after "cloud_types": true, add a comma and "abapdoc": true. Save.

3. Run the checks:

   Copy

   python unit13/mini_agent.py check

   You should see two new findings:

   Copy

    - abaplint: zcl_blocked_orders_rt1.clas.abap[10] Missing ABAP Doc for method count_blocked (abapdoc)
    - abaplint: zcl_blocked_orders_rt1.clas.abap[13] Missing ABAP Doc for method total_blocked_value (abapdoc)
   2 finding(s).

   If you see 0 finding(s), the abapdoc line didn't save; check the comma.

4. Fix them. With a key, run python unit13/mini_agent.py run --llm, read each diff and approve. Without a key, add these two lines yourself, each directly above its METHODS line, and save:

   Copy

       "! Counts the orders that have a credit block
       "! Sums the net value of the orders that have a credit block

5. Run python unit13/mini_agent.py check again.

6. Write three sentences in unit13/agent_demo/NOTES.md: what the rule is, how it is enforced, and what the log shows the agent did.

7. Commit: git add unit13 and git commit -m "Unit 13: ABAP Doc rule for the coding agent".

Done when check prints 0 finding(s)., AGENTS.md and abaplint.json both contain the new rule, and NOTES.md is committed.

#Check yourself