Chapter 5 - Plan Mode
Jumping straight from a requirement to code is a common trap — the AI starts editing files immediately, and by the time a wrong assumption surfaces, changes are already spread across multiple files. Plan mode breaks this pattern.
In plan mode the AI analyses your codebase and requirement, then produces a step-by-step implementation plan without touching any files. You read it, catch mistakes, and only then let the AI act. This turns debugging from reactive firefighting into a single sentence correction before anything changes.
Because no files are modified, plan mode is completely non-invasive — it leaves no trace in your codebase, your history, or your IDE. Nobody needs to know AI was involved; the output is simply a plan you can review, change and make it your own.
Plan mode is also a powerful brainstorming tool. Use it to explore multiple approaches to a problem, stress-test an architecture decision, or surface edge cases you hadn't considered — all before committing to any implementation. The result is a written specification: a clear, reviewable document you can validate against the requirements, adjust, hand off to a colleague, or discard entirely if the approach turns out to be wrong.
Use plan mode to design a structured, verifiable implementation plan before writing a single line of code.
- Reading time: 20 minutes
- Practical time: 40 minutes
Reading
Briefs
| Priority | Read This | Why It Matters |
|---|---|---|
| 1 | Plan -> Review -> Act | Introduction in how to work with Plan mode. |
| 2 | How to code with Agentic Tools | Various ways to approach the same solution. |
Practical
Before starting the practical part, make sure you have:
- Environment ready. If needed, complete Chapter 0 - Setup and Requirements first (Eclipse, ADT, GitHub Copilot, and Copilot subscription setup)
- Copilot CLI configured and setup based on Chapter 4 - Copilot CLI
- MCP Server configured and connected Chapter 2 - MCP Server
Note
While these exercises can be done within IDE, it is advised to do them using Copilot CLI.
Exercise 1 — Extend the Business Partner API with a New Field
The existing Business Partner API (C_BusinessPartnerTP_2) service exposes a set of standard fields. Your task is to add a new custom field and propagate it through every layer of the stack — CDS view, behaviour definition, service binding, and any consuming artefacts — without writing a single line of code, yet.
Goal: Use plan mode to produce a complete, reviewable implementation plan for the field extension. Evaluate the plan critically before allowing any action.
Step 1: Open plan mode
In Copilot CLI, prefix your request with /plan (or activate plan mode in your IDE's Copilot Chat panel) so the agent analyses the codebase and produces a plan without making any changes. Alternatively you can give a clear instruction to the Agentic AI to create a plan.
Step 2: Prompt the agent
Use a prompt that includes the following:
| Remark | Reason |
|---|---|
| Business Object to be Modified | The What? |
| The field to be added | The Who? |
| The naming convention for the extension and field to be added | The How? |
| The place you want to see the change | The Why? |
| Structure the plan | Influence the result in a Human/AI Readable format (ex.: Produce a numbered step-by-step implementation plan. ) |
| Location for the result | Make sure to specify where to write the plan for example a mark-down file like PLANEXT.md in the current folder |
Tip
Never assume that the AI knows all the information or it can deduce it. Unlike your colleagues who can make educated decisions based on prior knowledge, AI is unpredictable. There is no way to know what it will decide to do if not enough is provided.
Step 3: Review the plan
Read the plan the agent produces. Check the following before proceeding:
| What to verify | Red flag |
|---|---|
| Every CDS layer is listed (interface → projection → consumption) | A layer is skipped |
| The extension include a class extension to save the value of the field | The class is missing from the plan --> No update on the field |
| Service binding activation is included as a step | Plan ends at the CDS layer |
| OData annotations are present | Field visible in back-end only |
| Order of steps respects activation dependencies | Consumption view activated before interface view |
Information
A plan that references a file that does not exist in your system is a hallucination signal. If you see unfamiliar artefact names, ask the agent to confirm where it found them before you proceed.
Step 4: Refine if needed
If the plan is incomplete or makes wrong assumptions, correct it in the same chat session before acting.
The plan skips the projection view C_BUSINESSPARTNERTP_2.
Add a step to expose the field Z** there with a @UI.lineItem and @UI.fieldGroup annotation.
Update the plan without making any changes yet.Step 5: Save the plan
Once you are satisfied with the plan, save it as PLANEXT.md in your project root.
Important
Due to the context limitations, it might happen that it cannot store a detailed plan in memory. It often helps if you create the Plan file from the start and refine it afterwards.
Exercise 2 — Design a RAP Application for Library Management
You have been asked to build a greenfield RAP application from scratch. The domain: a library that owns books, organised across multiple rooms and shelves. No codebase exists yet — this is a pure design exercise.
Goal: Use plan mode to produce a full application blueprint, including data model, RAP behaviour, and service exposure. Treat the output as a specification you can review, challenge, and hand to any developer.
Note
Even if you do not have knowledge of how to build a RAP BO, you should be able to review the plan based on your knowledge or using AI to explain certain concepts. Most of the objects should be familiar, like database tables, CDS views and classes.
Step 1: Prompt the agent for a data model and architecture plan
Warning
Do not forget to refresh your copilot chat, either by using the command /clear or by restarting it.
Create a new plan, here are some information regarding the project:
- The library has multiple Rooms. Each Room has a unique RoomCode and a Name.
- Each Room contains multiple Shelves. Each Shelf has a ShelfNumber and a Capacity (integer).
- Each Book is stored on exactly one Shelf. A Book has: ISBN (key), Title, Author, PublishedYear, and Genre.
- Moving a book to a different shelf must be supported as a RAP action.
- Shelves must not exceed their Capacity (validation required).
- All objects should be restricted to a package you created
- Naming convention should contain your initial
Do not forget
Make sure to specify the location and file name to write the plan to, otherwise you will have to search for it.
Step 2: Evaluate the design
Use the checklist below to assess the plan before treating it as final.
| Design aspect | What to look for |
|---|---|
| Cardinality | Room 1:N Shelf, Shelf 1:N Book — both parent-child compositions present |
| Keys | All tables have a single ABAP-managed UUID key or a meaningful business key (ISBN for Book) |
| Capacity validation | Listed as a validation on the Shelf entity, not just a comment |
| Move action | Defined on Book with a parameter for target ShelfID |
| Naming | All artefacts start with Z* and contain the initial of the creator |
| Draft | Decision (enabled / disabled) is explicit and reasoned |
Step 3: Challenge the plan
Push back on at least one design decision to see how the plan adapts. Example challenges:
The current plan uses a UUID key for Room.
Change it to a human-readable RoomCode (CHAR4) and update all dependent artefacts in the plan.
Do not change any files.Add a second action to Book: CheckOut, which marks the book as currently borrowed
and records the BorrowDate. Update the plan only.There should be a split between maintaining the storage information, and the borrowing of books.Step 4: Save the final plan
Save the agreed plan as PLAN.md. You will implement it in Chapter 6.
Information
Greenfield design is where plan mode provides the most leverage. You can iterate through multiple architectural options in minutes — changing keys, cardinality, or feature scope — without touching a single file. Use it as a whiteboard before you commit to any structure.
What's Next
Continue with Chapter 6 - Implementing the Plan to execute the plan you just created and deliver a working SAP feature with AI assistance.