Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 6 of 6

From generated to production-ready: refactor, review and release

9 min

Listen to this lesson

0:00 / 6:39

Generated code reaches production in one of two ways: deliberately, after someone decides it's good enough to own, or by accident, because it worked in the demo. This lesson gives Elena's team a way to make the first happen. The core question is ownership: in two years, will someone on Contoso's team understand this code well enough to change it safely?

When generated code needs refactoring first

  1. Does the team understand every file it is about to deploy?Yes → continue · No → walk through it together or remove what nobody can explain
  2. Is business logic duplicated across handlers or between UI and service?No → continue · Yes → consolidate into one service handler
  3. Are names business words (Claim, serialNo) rather than generic (Entity1, field2)?Yes → continue · No → rename now; renames get costlier with data
  4. Are dependencies pinned and needed?Yes → continue · No → remove unused packages and pin the rest
  5. Do tests cover every rule (lesson 5)?Yes → ready for review · No → add tests before refactoring further
Five questions that decide whether generated code is ready to own.
The Sign-Off Table · thesignofftable.com/academy/sap-aid-205

Review rules for generated and agent-written code

  • Every change goes through a pull request in the team's repository; Business Application Studio and VS Code both work with git.
  • Label pull requests that contain generated code, and state which tool produced it (Joule, AI Chat with which provider, or which agent).
  • A second developer reviews models, authorization annotations and handlers line by line; generated CSV data is checked for personal data.
  • Changes to @requires, @restrict or role templates need the security lead's approval; at Contoso that is Nadia.
  • The pipeline runs npm test and lint on every pull request; a red pipeline blocks the merge.

Release path on BTP

SAP Build Code includes SAP Continuous Integration and Delivery and SAP Cloud Transport Management, and Contoso uses both. The pipeline builds the multitarget application archive from the main branch and hands it to Cloud Transport Management. The route is CMC_DEV to CMC_TEST to CMC_PROD: CMC_TEST imports automatically, Priya forwards to CMC_PROD after test sign-off, and CMC_PROD imports on a schedule in the approved release window. The subaccounts are cmc-ext-dev, cmc-ext-test and cmc-ext-prod.

Generated code adds two specific release risks. First, dependency drift: generators and agents add npm packages freely, and an unpinned dependency can change behavior between the test import and the production import. Pin versions and let the pipeline fail on unexpected changes. Second, regeneration: if someone later regenerates a part of the app with Joule, manual fixes made after the first generation can silently disappear. Treat regeneration as a code change like any other, reviewed in a pull request, and keep the tests that protect each manual fix so a regression fails the build.

Owning the app after go-live

Ownership means a named team, a backlog and a support path. For the claims app, Kenji's team owns the code, the after-sales process owner owns the rules, and Priya's team owns the regression pack that runs before every release. The agent is a tool the owning team uses, not an owner. When the after-sales team asks for a change, it starts as a requirement with acceptance criteria, which the developer turns into prompts and tests; the requirement, not the prompt, is what the test lead signs against.

Contoso's BTP release path: generated code travels the same route as any other code.
The Sign-Off Table · thesignofftable.com/academy/sap-aid-205
  1. Week 1Generate in SAP Build CodeModel, service, data, logic and UI with Joule; first review against the checklists
  2. Week 2Agent work in VS CodeMCP servers for model lookups and Fiori changes; tests strengthened
  3. Week 2, endRefactor and reviewNames, duplicated logic, pinned dependencies; security review of authorization
  4. Week 3Test in cmc-ext-testEnd-to-end scenarios against CMQ client 100 via CMC_S4HANA
  5. Week 4ReleasePriya forwards to CMC_PROD; scheduled import in the release window
Elena's four weeks, from first prompt to production.
The Sign-Off Table · thesignofftable.com/academy/sap-aid-205

What would you do?

Two weeks after go-live, a sales manager asks Elena to "just let the agent add a discount field to claims" directly in the production subaccount, because it's urgent. What does she do?

What would you do?

An auditor asks how Contoso knows which parts of the claims app were written by AI. What is the best answer?

Key points
  • Generated code is production-ready when the team can explain, test and own it.
  • Refactor names, duplicated logic and dependencies early; renames get costlier once data exists.
  • Label generated code in pull requests; authorization changes need the security lead's approval.
  • Generated code takes the same CI and Cloud Transport Management route as any other code.

Check your understanding · not graded

Lesson check

  1. 1. Which BTP transport route does Contoso use for the claims app?

  2. 2. Who forwards the claims app from CMC_TEST to CMC_PROD at Contoso?

  3. 3. Which change in a generated CAP app needs the security lead's approval at Contoso?