Skip to main content

Overview

When you are developing scripts on a shared development server, there are cases where it is hard to confirm, from your local environment alone, how code you wrote locally behaves in the shared server environment. However, making changes directly to the shared server's main environment, or redeploying or restarting it, just to verify behavior may affect other developers.

The AI-native Development Support Feature is a feature that meets this need: wanting to try your own code on the server without breaking the shared environment. It lets you move smoothly between your local machine and the shared development server when developing under the script development model. Incorporating it into the iAP development environment can also improve productivity in AI-native development using coding agents (Claude Code / OpenAI Codex / GitHub Copilot).

About the Name

The AI-native Development Support Feature is one of the features that make up Accel Orbit. For 2025 Spring to 2026 Spring, it is provided as a user module under its former name, "Development Support Module (velbench)." For how to install it, see Setup.

What You Can Do​

This is a development support feature that lets you take script assets you developed locally (on your own machine) and run them as-is on the shared development server. You can transfer (deploy) source code, configuration files, JARs, and other assets you developed in VSCode and similar tools to the shared development server, and by "switching" your own login session to those assets, you can verify your own code running in the remote environment.

Leveraging the AI-native Development Support Feature provides the following benefits:

  • Simplified asset deployment and management: It makes managing the development environment easy, including creating, editing, and deleting stagings; creating, editing, and deleting deployments; switching stagings; executing tenant environment setup; checking routing; and checking logs.
  • Achieving hot deployment: You can instantly apply the assets under development without restarting the application server or redeploying the war file.
  • Use of Accel CLI commands: You can deploy locally created assets directly to the development environment via the Accel CLI.
  • Use of MCP (Model Context Protocol): By having the coding agent retrieve configurations, logs, and annotations on the development server, you can obtain the information needed to generate applications and collect error information that occurs in applications under development, which can be used to improve the applications generated by the coding agent.

Problems It Solves​

The AI-native Development Support Feature solves the following problems:

  • You want to check behavior in a server environment that is hard to reproduce locally.
  • You want to try out only your own changes without breaking the shared server's main environment.
  • You want to share the same working environment with your team and verify behavior with the same assets.

This feature creates an independent workspace (a staging environment) for each developer and purpose, lets you deploy assets there, and lets you switch only your own session to that environment for verification. When you cancel the switch, you can return to the main environment at any time.

Target Users​

The AI-native Development Support Feature targets the following kinds of developers:

  • Developers who do script development on a shared development server.
  • Developers who want to run their local assets in a remote environment to verify them.

Intended Use and Constraints​

The environment built with the AI-native Development Support Feature has the following assumptions and constraints:

  • The AI-native Development Support Feature can be incorporated into iAP development environments of 2025 Spring or later. For 2026 Autumn or later, add it by selecting the application "Accel Orbit" in IM-Juggling; for 2026 Spring or earlier, add it as a user module (see Setup).
  • The AI-native Development Support Feature currently provided is an initial evaluation version, and its specifications may change or features may be added through future version upgrades.
  • Production operation is not assumed. For production environments, please separately consider a configuration appropriate for your use case and security requirements.

Basic Concepts​

This module is built around three concepts.

Staging Environment (Staging)​

A named, independent workspace that you create on the shared development server.

  • It is identified by a staging ID that you decide (e.g., my-app-staging).
  • You can register participants (owners) for one staging, and all participants can operate that staging on equal terms.
  • "Deployments," described below, hang off of a staging.

Deployment​

A single unit of transferring local assets to a staging environment.

  • You can deploy to the same staging as many times as you like (a new deployment is created each time you deploy).
  • Only the latest single deployment is ever active in a staging.
  • When you deploy again, the old assets that were previously active are automatically disabled (undeployed) and replaced with the latest ones.

Staging Switch (Staging Execution)​

The operation of switching your own login session to a specific staging.

  • Once switched, your subsequent script executions run on that staging's assets rather than on the main environment.
  • The switch affects only your own session. It does not affect other users.
  • "Cancel switch" returns you to the main environment.

The following diagram shows the relationship between deploying assets from local development to the staging environment and switching your own session.

The arrows represent deploying assets from local development to the staging environment, and switching a session to the staging. The staging environment retains only the latest deployment as the active assets, and a session that has switched runs on those assets.

For definitions of each term, refer to the Glossary.