What is IBM Bob? A closer look at its 2026 release

“Can we remove this?”

“I thought you knew what it did.”

You can imagine the exchange. Somewhere in a mature application is a function that nobody wants to touch. The comment says “temporary”, although it was written in 2021. The function still runs, of course. Before changing it, somebody needs to work out what depends on it and why it was added in the first place.

IBM Bob is IBM's AI coding agent, built to help with that sort of development work as well as new code. It can read and explain a project, prepare implementation plans, and write or refactor files. Developers can use its standalone IDE or Bob Shell at the command line; it also supports connections to other tools through the Model Context Protocol (MCP).

The product is interesting for reasons beyond generating code. Understanding a forgotten module, tracking a dependency or preparing a change for review can take a large share of an engineer's day. Bob gives teams another way to approach those jobs. The sensible question is where it helps in the software they already maintain.

Why does IBM Bob have Ask, Plan and Agent modes?

IBM separates three kinds of work. Ask is for reading and answering questions about code, without changing the files. Plan is for thinking through the work and producing an implementation approach. Agent can make the changes, including creating, editing and refactoring code. Each mode has different tool permissions.

Take a service that occasionally calculates the wrong delivery charge. A developer might begin with, “Where is this amount set?” Bob can inspect the code and identify the relevant functions. Then comes a second question: “What else uses that value?” If the answer reveals a billing integration or several dependent tests, there's more to discuss before editing anything.

That is where Plan earns its place. It gives the team something to inspect before Agent begins writing. Of course, the engineer may have found the answer in Ask and decide to make the correction personally. There is no obligation to put every ticket through all three modes.

IBM has also built in controls around file operations and command execution. Reading a repository and running a command that modifies it are different permissions, as they should be. The modes make that distinction easier to see.

A significant change for enterprise teams arrived in September

On 30 September 2026, IBM announced general availability of a self-hosted deployment option for Bob. The backend can run in supported customer-managed environments, including Red Hat OpenShift. Depending on the setup, organisations can use an external model service or models hosted on their own infrastructure.

That announcement is worth more attention than another feature added to a toolbar. Some engineering teams have source code, data-handling obligations or internal policies that prevent them from sending development context to a vendor-operated service. An arrangement where the organisation operates Bob's backend changes what those teams can consider.

It also means somebody has to operate it. Infrastructure, model selection, identity, updates and support do not disappear because the assistant has a friendly name. Those choices belong in the enterprise deployment discussion; the individual trial is a separate offer.

There was another development on 4 November. IBM published a guide to Bob's model router, which sends different tasks to different model tiers. A quick code explanation and a demanding implementation need not be handled in the same way. The exact model and usage behaviour still depend on the plan and environment, so teams should examine the setup they're evaluating.

IBM also has specialist Premium Packages for Java Modernization, IBM i and IBM Z. Those are relevant when existing systems and specialist platforms are part of the modernisation programme, with terms distinct from the standard developer trial.

What do 30 days and 50 Bobcoins buy you?

IBM currently advertises a free trial lasting 30 days, with 50 Bobcoins included. The standard offer covers the built-in modes and Bob Shell. IBM's website gives the registration conditions, which should be checked before anyone connects company material.

The name Bobcoin is memorable. The unit takes a little explanation, though: it measures AI resource consumption. One task might involve a short answer; another might search several files, generate a change and run commands. They won't necessarily consume the same amount. Fifty Bobcoins is a usage allowance, not fifty jobs completed.

There's a helpful real-world account in the IBM community. Writing about using Bob with Planning Analytics, contributor Ann Grete described around eight hours of interaction that consumed 11.3 Bobcoins. The work included creating and rebuilding an MCP server, troubleshooting a connection, writing a process and asking questions. It is one person's experience, published in September 2026, rather than a rate anyone else should expect.

For a trial, that example is more informative than an arbitrary promise about how many hours Bob will save. Keep the usage figure beside the work. It becomes much easier to understand what the allowance bought you.

Where I'd begin with an existing application

Pick a small job with a known result. Perhaps an API returns the wrong status code for one condition, or a documented rule is missing from a validation step. It helps if the team already has a failing test. You have a good basis for judging the outcome, without spending half the trial deciding what success looks like.

Ask Bob to explain the affected code first. If its answer points to a dependency you had forgotten, that's useful already. Review a plan if the change crosses several parts of the application, then allow Agent to make the edit on an approved branch. Look at the diff and run the tests that would have been required anyway.

Afterwards, talk about the whole job. Did the explanation help? Did anyone have to spend time correcting assumptions? What was the final Bobcoin consumption? A good answer might be “It helped us find the right file in minutes.” Another could be “The explanation was good; we preferred to write the fix ourselves.” Both tell you where the tool fits.

Try a second kind of work, such as documenting a component that new developers find difficult to understand. You'll learn something different from that exercise. At this stage, a handful of well-chosen tasks offers more insight than a grand productivity claim built on one demonstration.

What should happen before Bob sees company code?

IBM's security guidance covers approvals, file permissions and keeping credentials outside the content Bob can access. Its `.bobignore` file can exclude certain workspace files from Bob's tools, but IBM explicitly says it does not provide system-level isolation. That distinction matters when the same development machine holds credentials, customer data or operational configuration.

For a team considering broader use, the questions are familiar: which repositories are permitted, who approves a tool connection, and what actions must a developer confirm? There is more to these decisions than turning a setting on or off. Our article on AI agent identity and governance explores the related issue of who can authorise an agent to act on another application.

Existing software rarely lives alone, either. A changed field can affect an ERP interface, a partner API or a reporting process. The work around those dependencies is covered in our article on IBM webMethods and integration debt. An AI coding assistant may help with the implementation, but the team still owns the wider application behaviour.

Should your team give IBM Bob a try?

IBM separates three kinds of work. Ask is for reading and answering questions about code, without changing the files. Plan is for thinking through the work and producing an implementation approach. Agent can make the changes, including creating, editing and refactoring code. Each mode has different tool permissions.

Take a service that occasionally calculates the wrong delivery charge. A developer might begin with, “Where is this amount set?” Bob can inspect the code and identify the relevant functions. Then comes a second question: “What else uses that value?” If the answer reveals a billing integration or several dependent tests, there's more to discuss before editing anything.

That is where Plan earns its place. It gives the team something to inspect before Agent begins writing. Of course, the engineer may have found the answer in Ask and decide to make the correction personally. There is no obligation to put every ticket through all three modes.

IBM has also built in controls around file operations and command execution. Reading a repository and running a command that modifies it are different permissions, as they should be. The modes make that distinction easier to see.

A significant change for enterprise teams arrived in September

On 30 September 2026, IBM announced general availability of a self-hosted deployment option for Bob. The backend can run in supported customer-managed environments, including Red Hat OpenShift. Depending on the setup, organisations can use an external model service or models hosted on their own infrastructure.

That announcement is worth more attention than another feature added to a toolbar. Some engineering teams have source code, data-handling obligations or internal policies that prevent them from sending development context to a vendor-operated service. An arrangement where the organisation operates Bob's backend changes what those teams can consider.

It also means somebody has to operate it. Infrastructure, model selection, identity, updates and support do not disappear because the assistant has a friendly name. Those choices belong in the enterprise deployment discussion; the individual trial is a separate offer.

There was another development on 4 November. IBM published a guide to Bob's model router, which sends different tasks to different model tiers. A quick code explanation and a demanding implementation need not be handled in the same way. The exact model and usage behaviour still depend on the plan and environment, so teams should examine the setup they're evaluating.

IBM also has specialist Premium Packages for Java Modernization, IBM i and IBM Z. Those are relevant when existing systems and specialist platforms are part of the modernisation programme, with terms distinct from the standard developer trial.

What do 30 days and 50 Bobcoins buy you?

IBM currently advertises a free trial lasting 30 days, with 50 Bobcoins included. The standard offer covers the built-in modes and Bob Shell. IBM's website gives the registration conditions, which should be checked before anyone connects company material.

The name Bobcoin is memorable. The unit takes a little explanation, though: it measures AI resource consumption. One task might involve a short answer; another might search several files, generate a change and run commands. They won't necessarily consume the same amount. Fifty Bobcoins is a usage allowance, not fifty jobs completed.

There's a helpful real-world account in the IBM community. Writing about using Bob with Planning Analytics, contributor Ann Grete described around eight hours of interaction that consumed 11.3 Bobcoins. The work included creating and rebuilding an MCP server, troubleshooting a connection, writing a process and asking questions. It is one person's experience, published in September 2026, rather than a rate anyone else should expect.3

For a trial, that example is more informative than an arbitrary promise about how many hours Bob will save. Keep the usage figure beside the work. It becomes much easier to understand what the allowance bought you.

Where I'd begin with an existing application

Pick a small job with a known result. Perhaps an API returns the wrong status code for one condition, or a documented rule is missing from a validation step. It helps if the team already has a failing test. You have a good basis for judging the outcome, without spending half the trial deciding what success looks like.

Ask Bob to explain the affected code first. If its answer points to a dependency you had forgotten, that's useful already. Review a plan if the change crosses several parts of the application, then allow Agent to make the edit on an approved branch. Look at the diff and run the tests that would have been required anyway.

Afterwards, talk about the whole job. Did the explanation help? Did anyone have to spend time correcting assumptions? What was the final Bobcoin consumption? A good answer might be “It helped us find the right file in minutes.” Another could be “The explanation was good; we preferred to write the fix ourselves.” Both tell you where the tool fits.

Try a second kind of work, such as documenting a component that new developers find difficult to understand. You'll learn something different from that exercise. At this stage, a handful of well-chosen tasks offers more insight than a grand productivity claim built on one demonstration.

What should happen before Bob sees company code?

IBM's security guidance covers approvals, file permissions and keeping credentials outside the content Bob can access. Its `.bobignore` file can exclude certain workspace files from Bob's tools, but IBM explicitly says it does not provide system-level isolation. That distinction matters when the same development machine holds credentials, customer data or operational configuration.

For a team considering broader use, the questions are familiar: which repositories are permitted, who approves a tool connection, and what actions must a developer confirm? There is more to these decisions than turning a setting on or off. Our article on AI agent identity and governance explores the related issue of who can authorise an agent to act on another application.

Existing software rarely lives alone, either. A changed field can affect an ERP interface, a partner API or a reporting process. The work around those dependencies is covered in our article on IBM webMethods and integration debt. An AI coding assistant may help with the implementation, but the team still owns the wider application behaviour.

Should your team give IBM Bob a try?

The 30-day trial is a reasonable starting point for developers curious about Ask, Plan and Agent on a codebase they know. Bob's newer deployment options also make it relevant to enterprises that previously had limited room to explore hosted coding agents.

I'd begin with an ordinary maintenance request, preferably one that has been waiting in the backlog and has a test to prove when it is finished. Give the developer room to investigate, use the modes as they make sense, and see what the team takes away from the exercise. For larger adoption questions, Phases works with enterprises on the software, integrations and engineering arrangements around tools like this.

Try IBM Bob

The standard trial currently includes 30 days and 50 Bobcoins. Phases receives referral credits when someone registers through the trial link in this article. The registration page provides the applicable terms.

Try IBM Bob for Free