Every conversation about IBM’s Bob Premium Package for i eventually lands on the same question, and it isn’t “does it work.” The demos are genuinely impressive: natural-language database archaeology, SQL review and rewrite, security log interrogation, RPG modernization workflows, all running directly against a live IBM i connection. The question that actually keeps technical leads up at night is simpler and less glamorous: what does it cost to let a whole team use this, and how do you keep that number from getting away from you?
This isn’t a Bob review. It’s a proposal for how to govern Bobcoin — IBM’s consumption-based billing unit — before decentralized, duplicated, or purely curious usage turns a promising tool into an unpredictable budget line. It’s written for technical leads and engineering managers who are past the “should we try this” question and into the “how do we run this responsibly at scale” one.
What a Bobcoin Actually Buys You
The mechanics are straightforward on paper. A Bobcoin is worth fifty cents. Plans range from a 40-coin free trial up through a 500-coin Ultra tier, with the IBM i premium capability sold as a separate monthly add-on. If a team burns through its allotment, the vendor’s answer is to simply turn on overage billing and keep paying per coin consumed.
What’s harder to plan around is that there’s no way to know what a task will cost before you run it. In a live demonstration of the tool, when asked directly about estimating cost up front, the honest answer was “it depends” — some tasks consumed a fraction of a coin, others consumed several, and running multiple agent tasks in parallel simply multiplies the draw. The practical guidance offered was to watch a usage dashboard and build intuition through experimentation.
The wider IBM i community is already reacting. Practitioners comparing notes on realistic day-to-day costs generally land well above the entry-level tier once actual daily use and overage charges are factored in. A sharper critique has emerged too, from people who work with these tools professionally: Bobcoin adds a second, vendor-defined layer of opacity on top of an already-opaque token economy, and there’s a real temptation to measure developer productivity by how many coins someone burns rather than by what they actually deliver. Reward the wrong behavior and you’ll get more of it.
The Price Was Never the Problem
Here’s the argument this piece wants to make: the danger was never really the price of a Bobcoin. It’s what happens when usage is left entirely to individual discretion.
Picture the default, ungoverned adoption path. Five developers each open Bob against the same legacy application. Each independently asks it to explain the same program, generate their own entity-relationship diagram, run their own impact analysis, maybe follow their own curiosity into an audit journal or a performance question that has nothing to do with their actual task. None of that is wasteful in isolation — some of it is genuinely delightful, which is exactly the problem. Curiosity is a wonderful trait in a developer and a terrible input into a metered billing system.
Treating this as a matter of personal restraint — “just be mindful of your coins” — is the wrong frame. It’s an organizational design problem, not a willpower problem, and it deserves an organizational answer. Productivity-by-token-count is also a bad metric on its own terms: it punishes the developer who solves a problem efficiently in one focused pass and rewards the one who wanders. Any team that adopts it will optimize for the wrong thing without noticing.
How to Actually Govern It
The fix is to stop treating AI-assisted research as something every developer does for themselves, and start treating it as a produced, reusable asset.
Introduce a dedicated role: a Context Broker — think Team Lead, PM, or whichever agile equivalent already scopes and controls work in your shop — whose job is to own the expensive, one-time context-building work. When a change request comes in, the Context Broker is the one who uses Bob to generate the program documentation, the impact analysis, the relevant diagrams, and the test plan. That output gets packaged into a unit of work (UOW): a defined bundle containing the programs and objects involved, the artifacts Bob produced, and a clear scope of what needs to change. The UOW gets checked into a repository as a durable, reusable asset rather than evaporating after one session, so the next request touching the same program doesn’t pay to regenerate context that already exists.
Developers work from the UOW to build their own context for Bob. They implement the defined changes and raise clarifying questions against that local context rather than opening their own exploratory sessions — the difference between a cheap, scoped question and an expensive, open-ended one is exactly the line worth protecting.
Not every request deserves the same treatment, so the Context Broker should tier incoming work by complexity before touching Bob at all — a one-line field expansion doesn’t need the same depth of analysis as a monolithic-to-modular refactor. And because curiosity shouldn’t simply be banned, it should be budgeted: a small, separate, capped allowance exists specifically for exploratory or learning use, walled off from delivery budgets, so experimentation can continue without silently consuming project spend.
For tracking, UOWs flow into whatever ticketing system the team already lives in — a natural fit given Bob’s MCP integration — with each ticket carrying links to the repository artifacts, the defined scope, and a field logging the Bobcoin cost of producing that bundle. That turns an ad hoc AI workflow into something trackable and auditable inside tooling teams already use daily, with ticket creation and updates staying under the Context Broker’s control so the audit trail doesn’t fragment.
Before any of this scales past a pilot, run it small. A handful of developers under one Context Broker for four to six weeks builds an actual empirical baseline of what routine tasks cost in coins — documentation, impact analysis, format conversion — replacing “it depends” with real numbers your organization owns. From there, set an explicit approval threshold before overage spend kicks in, so nobody discovers a surprise bill after the fact, and track coins-per-UOW and artifact-reuse-rate as the real KPIs, rather than falling back into counting individual token usage.
What Governance Actually Buys You
None of this requires Bob, or any agentic AI tool, to become cheaper or more transparent on its own. It requires the organization around it to be deliberately designed: the Context Broker owns the expensive research, that research becomes a reusable asset instead of disposable output, effort is tiered to match actual complexity, curiosity gets its own small budget instead of an unlimited one, and existing project tooling carries the audit trail. Do that, and “it depends” turns into a number a manager can actually forecast, defend, and improve over time.
This model scales the way any lead-and-team structure scales — by adding more teams, each with its own Context Broker and set of developers, rather than by hoping restraint holds as headcount grows. The unexpected upside is that multiple teams generate real comparative data: once two or three of them are tracking coins-per-bundle, an organization has internal benchmarks no single team could produce alone, and a natural incentive to find and share what’s actually driving efficient use.
Zoom out further and this stops being a Bob-specific story. Every vendor selling metered, agentic AI tooling is going to hand engineering organizations some version of this same problem — a unit of consumption that’s hard to predict and easy to spend without noticing. The teams that design real governance around it early, rather than treating cost as an afterthought to be absorbed later, are the ones who’ll get to keep using these tools enthusiastically instead of nervously.
How is your team tracking what its AI-assisted work is actually costing — and who owns that number? Get in touch.