Nobody Knows What CSTNM Means. IBM Bob Was Built for That File

So what is Bob#

Bob is IBM’s AI coding partner. It became generally available on April 28, 2026, and a big second version came out in Bob IDE on June 24. Bob Shell, the terminal version, got it on August 5. Bob IDE is a desktop app, and since September Bob also plugs into IntelliJ, Neovim and Zed.

Bob doesn’t use one model. It uses a mix of Anthropic’s Claude, Mistral and IBM’s own Granite models, and a router picks which one does which job. You don’t choose. According to IBM’s FAQ, your company can’t restrict the choice either. The one exception is a self-hosted install, where you bring the model yourself.

Some developers like that, some don’t. Kate Holterhoff, a senior analyst at RedMonk, told The Register it’s “a double edged sword”: developers can be suspicious of black box tools, but it also saves them from “the paralysis of choice”. That’s fair on both sides. And in a bank it’s more than a taste thing. Which model saw this code is a question compliance will ask.

Before it went public, IBM tested Bob on its own people. The rollout started in June 2025 with a hundred developers and passed 80,000 by launch. By November, IBM’s count was 170,000. IBM says teams saw a 45% productivity gain on complex, multi-step work. That number comes from an internal survey where people reported it themselves. Keep that in mind.

Now, there are a lot of AI coding tools. Here’s where Bob is different.

The hard part was never writing the code#

There’s a stat in IBM’s July announcement that I keep thinking about. It’s from GitLab’s 2026 AI Accountability Report, a Harris Poll survey of 1,528 people in six countries. 85% of them agree that AI moved the bottleneck. Writing code is not the slow part anymore. Reviewing and validating it is.

Old code is the extreme version of that problem. Before you change one line, you have to understand what the program does. And with old code, the people who could explain it are gone, the documentation is gone, and sometimes the language itself is something nobody at the company learned in school.

That’s where IBM is pointing Bob. On top of the regular plan, IBM sells optional add-ons called premium packages. There are four now. One is for DevSecOps. The other three, which IBM put in one announcement in July, are all about old code.

One is for IBM Z, the mainframe. It works with COBOL, assembler and REXX, and analyzes JCL, the job scripts that run mainframe batch work. It’s for Enterprise customers only, on a yearly contract.

One is for IBM i, IBM’s system for business servers, where a lot of RPG code lives. It covers RPG, CL, DDS, SQL and Db2 for i, and costs 40 dollars a month.

And one is for Java, for moving apps off Java 8 or 11 onto 17, 21 or 25, and off WebSphere onto Liberty, IBM’s lighter Java runtime. That one is 20 dollars a month.

IBM says the Z package brings “AI-native application modernization to IBM Z for the first time.” It’s not IBM’s first AI tool for the mainframe, though. There was watsonx Code Assistant for Z before, and IBM calls the new package “an evolution of” it. You can see why IBM cares so much. The mainframe is IBM’s home turf.

Step one: just ask#

See, the first thing I’d want from an assistant on old code is for it to not touch anything.

Bob has three modes. Ask mode only reads and explains. It can walk you through the architecture and the logic, and according to the docs it doesn’t have the tools to edit files or run commands. It also can’t switch itself into another mode, because the mode switch isn’t on its tool list.

One thing to know: Ask can still use the MCP tools you connected. If one of those tools can change something, Ask can too.

Plan mode writes a plan you can review, and it can only edit Markdown and text files. Agent mode does the work.

For old code, Ask is where you live for a while. And there’s a small feature I like a lot here. Bob can turn its analysis into one HTML page that opens in any browser, so you can send it to someone who wasn’t in the session. Think about who that someone is. Your manager. The new person on the team. The auditor. The one person who still remembers the system and could tell you if Bob got it wrong.

IBM’s hands-on lab for IBM i goes a step further. It’s a learning plan on the IBM Community site, written by Bob’s customer success team in May. One of its prompts asks Bob to read the RPG programs and write a folder of Markdown docs with architecture diagrams: which program talks to which, where the data lives, how the control flows, with the legacy parts highlighted. That’s a first draft of the documentation nobody wrote.

One catch. The lab gives you the prompts, not what Bob made from them. I don’t know how accurate those diagrams are on a messy codebase, and I couldn’t find anyone outside IBM and its customers who has published that yet.

There’s also a newer, cheaper way to get the map on IBM i. Since September, the IBM i package has a feature called Understand. An IBM i news site wrote it up on November 9. Instead of reading every line of source, it collects what the system already knows about each object: who calls it, what it calls, which files and tables it uses. Then you ask Bob plain-English questions about the whole application. Because it works from that metadata, it barely touches your usage allowance. In IBM’s demo, an ERP application with more than 7,000 objects came down to 13 entry points in seconds. That’s IBM’s demo, on IBM’s stage, but the idea is sound. Ask the system what it knows before you pay to read the code.

Over the same few months, IBM also taught Bob to read the even older, fixed-format dialects of RPG. That matters, because the oldest code is exactly the code nobody can explain.

A first draft of a map is a lot better than no map.

Step two: give the variables real names#

Now back to CSTNM.

There’s a reason old RPG variables look like that. In the older versions of RPG, a name could only be six characters long. So “customer name” became CSTNM, and “total amount due” became something like TOTDUE, and after thirty years you have thousands of these. Modern RPG allows names up to 4,096 characters. The old programs just never caught up.

One of the tasks in IBM’s lab is exactly this. You point Bob at a file and ask it to rename the six-character variables to descriptive names and to “preserve all business logic”. Another task converts fixed-format RPG, where every character has to sit in a certain column, into free-form RPG that a younger developer can read without a ruler.

Renaming sounds like a small job. With old code it’s the first step, because you can’t fix what you can’t read.

Now here’s a number from outside IBM to put next to the lab. In October, two IBM i developers, Dan Darnell and Eric Whitcomb, wrote up their own experiment with Bob version 2 for the IBM i news site IT Jungle. They were on Pro Plus with the IBM i package, 100 dollars a month for 160 Bobcoins. Building one new maintenance program from scratch, with a database table, RPG services and a web front end, cost them 18 Bobcoins. Failed runs cost coins too, and one run went into a loop they had to stop. At that rate, they wrote, a month of coins lasts about ten working days.

Their advice on the fixed-to-free conversion is the opposite of what the lab suggests. They wouldn’t use Bob for it. Mostly because of cost: for large syntax upgrades they called 160 Bobcoins “wildly insufficient”. They also noted that AI output isn’t always consistent, and that there are purpose-built conversion tools, some of them cheaper, that don’t need AI at all.

So here’s how I’d split the work. Renaming needs someone to understand what the code means, so that’s a job for Bob. Moving characters out of columns is mechanical, so price a plain converter first.

Use the AI where a person would have to think.

Step three: the Java upgrade nobody wants to do#

The Java package is the one more people will touch, because a lot of companies still run old Java.

There’s a guided workflow for it. In the current docs you start it from a Start Workflow button, or with a slash command:

1
/start-java-mod

IBM’s lab still uses an older command name, so if you follow the lab, don’t be surprised when it doesn’t match.

Bob looks at your Java files and gives you upgrade recommendations. The lab also lists charts of cost, time and token usage, which is a nice touch when you have to explain the project to someone with a budget.

Moving from WebSphere to Liberty needs one more thing first. The docs ask for a migration bundle from IBM’s Application Modernization Accelerator, which is a separate assessment tool. So that part doesn’t start from zero inside Bob.

Here are the numbers IBM puts on modernization. In the July announcement, Saireshan Govender, Group CEO of Blue Pearl, an IBM partner, says a legacy modernization effort planned for nine months with fourteen engineers was done in three days. The announcement doesn’t say what kind of code it was.

IBM’s own case study about Blue Pearl tells a smaller story. There, the project is upgrading the company’s BlueApp from Java 11 to Java 25, and the time goes from about thirty days to three, with more than 160 hours saved. Maybe those are two different projects. IBM doesn’t say.

These are vendor numbers, from a partner. Maybe they’re true for that project. Your project is not that project. What I’d take from it is the direction: the boring, careful, months-long upgrade is the work IBM thinks Bob is best at. And I’d test it on one small service before I promised anyone three days.

Undo, without needing Git#

This next feature matters a lot more on old code than on new code.

In version 2, Bob got rollback. IBM’s release post says it tracks the state of your files for each task, each turn of the conversation and each tool call, and you can go back to those points. In version 1, checkpoints were built on Git, so a project without Git got no checkpoints at all. Version 2 tracks the files itself.

Why does that matter? Because some old code doesn’t live in Git. Some of it lives on a shared drive, or in a folder called “final version two, the real one”. If the assistant made a mess in a folder like that, you still want an undo button.

Two things before you count on it. The rollback docs say changes made outside a Bob task aren’t captured, so if you fix something by hand between tasks, Bob’s undo doesn’t know about it. And I couldn’t find in the docs whether rollback covers files on a remote system, like a mainframe, so I wouldn’t count on it there.

Bob also got subagents in version 2. A big job can be split into smaller jobs, and each one runs with its own clean memory. Only a short summary comes back to the main conversation. With a huge old codebase, that keeps Bob from drowning in its own notes. Each new subagent also asks for your approval before it starts, which I like.

The money part#

Bob doesn’t charge you by tokens. It charges in Bobcoins. Every action, like writing code or running a command, costs some Bobcoins, depending on how much compute it needs.

The model matters too. According to IBM’s post on the model router, the router picks a tier when a task starts, and the tier sets the price. You don’t pick the model, so you can’t know exactly what a task will cost before it runs.

According to the Bob docs right now, the Pro plan gives you 50 Bobcoins a month, Pro Plus gives you 180 and Ultra gives you 1,000. IBM’s pricing page says Pro starts at 20 dollars, Pro Plus at 60 and Ultra at 200, and prices vary by country. There’s a 30-day free trial with 50 Bobcoins.

Those allowances changed on September 24. Before that, it was 40, 160 and 500, and the 160 that Darnell and Whitcomb had was the old Pro Plus number. So when you read an older article, check the date.

When you run out, you can turn on overage, and every extra Bobcoin costs 50 cents.

And here’s the part I’d put on a sticky note. Once you turn overage on, you can’t turn it off until the end of the month. It switches itself off when the new month starts, and you can raise or lower the limit any time. So set a limit you’re okay with before you turn it on.

To see where the coins go, there’s a little gauge in the top-right corner of the Bob panel. On Pro, Pro Plus and Ultra, that gauge is what you get. Enterprise customers also get Bobalytics, a dashboard that shows usage over time across the team. For a long modernization project, that’s the screen the person paying will want to see every week. So if your company is the one paying, ask which plan you’re on before the project starts.

Opening code you didn’t write#

There’s one more thing I want you to know before you open old code with any AI agent, Bob included.

When you work with old code, you open something somebody else wrote and you ask, “what is this?” That code can have anything inside it, including text written for an AI to read, hidden in a file like a README.

This has already happened to Bob. In January, while Bob was still in a closed beta, the security firm PromptArmor showed how, and The Register wrote it up. They hid instructions at the bottom of a README. The user only asked Bob to explain the repo. Bob Shell then asked to run a harmless echo command, again and again, until the user picked “always allow” for it. The next command also started with echo, but it carried a download inside it. It fetched a script and ran it, and nobody was asked.

IBM said Bob was a tech preview at the time, and that it would fix things before general availability. Its docs already called auto-approve high-risk. I couldn’t find a public note saying those exact gaps were closed. The Bob Shell changelog since August does tighten auto-approve.

Bob has a setting for this now, and it’s the one I’d tell every team about. It’s called workspace trust, and it arrived in August. The first time you open a folder, Bob asks whether you trust it. If you say no, Bob opens it in a safe mode: no project settings, no MCP servers, no project skills or rules, no agent instruction files, and auto-approve is off. IBM’s Bob Shell docs say to mark third-party repositories as untrusted before you run Bob on them in CI.

So when you explore code you didn’t write, open it as untrusted first and stay in Ask mode. Don’t put commands on “always allow” while you’re still looking around.

Not even echo.

Two more details. Since version 2, reading files, listing folders and searching code are approved by default, so Bob looks around without asking. And the file that tells Bob what to ignore “does not create a system-level sandbox”, in the words of IBM’s security guidance. If something must not be read, keep it out of the folder.

I learned this lesson with a different agent. I told it in writing that it was read-only, and the audit log said 25 writes. A rule in a prompt is a wish. A setting the tool enforces is a control.

What your security team will ask#

If you work in a bank, or anywhere with a CISO, these questions come before the first prompt. Here’s what IBM says.

IBM says prompts and code are not used to train models, and are kept only for the interaction, “on the order of minutes”. The cloud version runs in three regions: the eastern United States, Europe and Japan. Your conversations stay in the region you pick, and account and billing data sit in the eastern United States. Since September 24, Enterprise customers can run Bob on their own Red Hat OpenShift instead, with a model they supply. IP indemnity is Enterprise only.

And on the cloud version, nobody at your company can pick or restrict the models. Write that down before procurement asks, not after.

The person who is leaving#

The Register put it bluntly in April: on many mainframes, knowledge and expertise is “literally dying off or has been long exported offshore”. That’s the reason tools like Bob exist, and it’s also the risk.

The person who could look at Bob’s diagram and say “no, that’s wrong, that job runs on Sundays only” is the person who’s leaving. If you have that person, get them in the room while Bob does the first pass. That HTML summary is a pretty good thing to put in front of them.

They’re also the only accuracy test you have right now. The write-ups from outside IBM so far describe what Bob does and what it costs. I haven’t found a public, independent test of how often it gets old code right. Until someone publishes one, the person who knows the system is your benchmark.

Who Bob is for#

If you write new web apps all day, there are plenty of AI tools for you, and Bob is one more option.

If you work at a company with a mainframe, an IBM i box in the basement, or a Java app that’s still on Java 8 because “it works”, IBM has been building for you for a while. Bob puts the old-code tools and a regular coding agent in one place.

What I’d do first:

1. Open the old code as an untrusted folder, in Ask mode, and ask Bob to explain one program you think you already understand. See if it gets it right.
2. On IBM i, try the Understand map before you pay to read the source.
3. Have Bob make the HTML summary and show it to whoever knows the system best.
4. Try the rename on one file and run your tests. Old code usually has fewer tests than you’d like, so check that first.
5. Before a big format conversion, price a plain converter against your Bobcoins.
6. Set an overage limit before you turn overage on.
7. Keep “always allow” off while you’re exploring a repo you didn’t write.

That’s it from me. Now tell me, what’s the worst variable name you’ve found in old code? I’m collecting them. The comments are open, and that is where I answer first.