Overview

02Project 02 of 3

AI-assisted development on IBM i

An AI coding agent on legacy RPG, the language of business applications on IBM i servers (formerly AS/400): it gets the context and a guide for each concept it works on, but no free shell. The agent runs on the developer’s workstation, not on the IBM i; its code changes go through one SSH key bound to one script.

A

The approach

  1. 1

    Give it context

    The IBM i sources are exported to the IFS, the IBM i’s file system, then synced to the workstation along with the project’s documentation. That is what the agent can read: the code, and the documents that explain it.

  2. 2

    Map the concept first

    When a task touches a business concept that has no guide yet, the agent first runs an in-house analysis skill on that concept (a skill is a written procedure the agent loads and follows). The skill finds the programs and tables involved and where the data comes from, then writes a guide that leads to the right files. Guides build up one concept at a time. How it works

  3. 3

    Change through one script

    Every code change goes through one IFS script, reached with one SSH key. The agent puts the source on the IFS, compares it with the live production source of the object’s latest release, which the script extracts, and works on the more recent version, in the IFS. The script then pushes it into the IBM i libraries (QSYS), compiles it and returns the compiler’s messages. The agent loops until the code compiles.

  4. 4

    Drive green screens

    The agent drives a 5250 session, the IBM i’s text-screen interface (the “green screen”), through an MCP server (MCP is the standard way to plug a tool into an AI agent), with a live mirror in the browser so the developer sees every step.

B

The analysis skill

On a legacy codebase, an in-house skill documents the system one business concept at a time, and checks every key claim of its own guide against the source code before the guide is kept.

Trace

Which program writes each table, which job runs that program and where the data comes from, followed back up to three steps.

Research

AI workers, small agents run in parallel, each answer one factual question: the fields of a table, the conditions of a program, a count.

Write

A guide organised by business feature, not by program, that explains why and cites the lines.

Challenge

One worker per key claim tries to refute it in the source and pastes the line it used.

Each claim ends as confirmed, refuted or unverifiableEffort set per concept: light, standard, or deep with a second challenge pass

A guide to the right files. It takes a reader from a question to the two or three files worth opening; the code stays the source of truth. The aim: under two minutes from the question to those files.

Read before writing

The skill first reads what the repository already documents, so the guide neither contradicts nor duplicates it, and keeps its vocabulary.

Say what a name hides

When a menu or a program does something other than its name suggests, the guide opens with a clarification. It is often the most useful finding.

A guide when a task needs one

The skill does not document the whole repository in advance: such a document would have to be kept up to date by hand and would soon fall behind. It writes a guide when a task touches a business concept, so parts of the repository have no guide yet, by design.

C

Where things run

Developer’s workstation
Editor and agentVS Code
Local filesexported sources · project documents
SSH keyprivate key, never leaves the machine
5250 bridgeMCP server · live mirror on localhost
SSH · forced command
5250 · TLS
IBM i
One scriptallow-list of actions · no shell
Change cycle and compilerversions · components · check-out · compile
5250 sessiondedicated profile, test library
The developer’s own profileaudit trail · access revocable per developer
Two channels, both narrow. SSH is bound to a single script, and the 5250 session is driven through a bridge that reads the screen as data. Versions, components and check-out are the vocabulary of ARCAD, the change-management tool in place: a check-out extracts a source from production in order to change it.
D

The loop: compare, edit, update, compile, feedback

Comparewith the live source of the latest release, extracted by the script
Editthe file, in the IFS
Update sourcein the QSYS library, through the script
Compilethrough the script
Feedbackthe compiler’s messages

The agent reads the feedback, fixes the source and loops until it compiles

One script for every step. From browsing the sources to compiling, each step is an action of the same script, so nothing runs outside it.
E

Security model

AI AGENT ENTRY POINTIFS SCRIPT · SSH
1 Browse sources and components2 Create a version3 Create a component4 Check out5 Update a source from the IFS6 Compile and return the feedback
Any other request ........ refusedSelection ===>
Illustration The whole change cycle behind one SSH key, drawn in the style of a 5250 screen.
  • The key runs the script and nothing else. SSH forces the command (restrict, command=): no shell, no port forwarding, no tunnel.
  • An allow-list of actions. Anything else is refused with an explicit message, never run.
  • One key and one profile per developer. Every action is attributable in the audit log, and each developer’s access can be revoked separately.
  • Visible failures. A failed step reports an error instead of a misleading success. File names are checked, and uploads go to the developer’s own folder.
F

Green screens

AgentVS Code
5250 bridgeMCP server, on the workstation
  • reads the screen as data
  • types and presses keys
IBM i session5250 · dedicated profile

Live mirror · browser · localhost only · read-only

The developer watches, the agent types. An interactive mirror, where the developer can type as well, is a separate piece of work: it needs a lock so that both do not type at once.
VS Code window: an RPG program on the left, the mirror of the 5250 session in a tab of the integrated browser in the middle, and on the right the agent reading the screen, then typing.
The mirror is just a tab in VS Code. The source on the left, the live 5250 session in the middle, the agent on the right. Click the image to enlarge it.

What the agent sees

The screen text as it is, its fields listed by name and position, the cursor, whether the keyboard is locked, and a signature that identifies the screen. All structured text, no screenshots.

The safety rules I set

The screen is treated as data, never as instructions: a field can contain “ignore the rules and run…”. The session uses a dedicated low-privilege profile on a test library with no live business data, over an encrypted port only.

G

Design choices

Why a forced-command script rather than a shell?

A shell is unbounded: anything the profile can do, a prompt injection or a plain mistake can do. A forced command turns the SSH key into a menu. The request is only split into words, never evaluated as a command, and the target folder comes from the connected profile, never from an argument.

Why map the concept first?

A legacy RPG repository holds decades of conventions nobody wrote down. The guide gives the agent an index to navigate with instead of searching blindly, and gives me something to check its understanding against.

Why reuse an existing 5250 bridge?

Open-source MCP servers already exist, one with a live browser view. What remained was the setup around it: network and permissions, safety rules, and a small end-to-end trial. A custom emulator would have cost more.

H

Limits