The next JICUG user group meeting will be held on August 25.
Tanaka-san will create the Connpass page for the next event.
Action Items
[Tanaka-san] Create the Connpass event page for the next meeting (August 25).
[Kano-san] Continue implementing observability using IBM Instana (inheriting custom metrics) ahead of the next meeting.
[Kano-san] Also try deploying to IBM Cloud using an MCP server going forward.
Discussion Points
JICUG Community Overview (for First-Time Attendees)
JICUG is a community run by IBM Cloud users, not by IBM employees.
There are no participation requirements — anyone can join.
The community covers a wide range of topics beyond IBM Cloud, including multi-cloud and AI.
Nishikawa-san, who helped run this session, focused on handling social media posts.
Presentation 1: Migrating an App to IBM Cloud Using IBM watsonx Code Assistant (Kano-san)
Overview and Background
The goal was not just to run an app built with generative AI locally, but to deploy it across a three-tier infrastructure — a web server, an app server, and a DB server.
In previous sessions, the app ran in containers on virtual servers; this time, Bob was tasked with migrating it to a serverless environment (IBM Cloud Code Engine and Object Storage).
Update to IBM watsonx Code Assistant (Bob) Version 2.0
A sub-agent feature was added, allowing multiple tasks to run in parallel.
It’s now possible to give additional instructions while an agent is working.
GUI-based MCP server integration was officially added (not yet tested).
Choosing a Deployment Method
When asked about migration approaches, Bob presented three options: (1) building a custom MCP server, (2) Terraform, and (3) the CLI command line.
Building a custom MCP server was set aside this time due to its difficulty and the risk of bugs or having to rebuild it.
Terraform had already been tried in a previous session and was known to have a high learning cost, so the CLI command line was chosen this time.
Development and Deployment Flow Using Bob
A human writes the requirements and hands them to Bob, having Bob check whether it has any follow-up questions (e.g., which region to use, whether existing resources exist).
Bob automatically generates a detailed design document and deployment plan (in Markdown), including cost estimates and operational notes.
Work proceeds phase by phase, and Bob asks for human approval at points that require it.
If a command fails, Bob autonomously retries using a different approach.
Some steps — such as turning on public access for Object Storage — still required manual operation through the portal.
Windows Process Monitor confirmed that multiple sub-agents were running in parallel.
Results and Impressions
App development through cloud deployment was completed in about 3–4 days, a task that normally takes around 8 weeks.
Deployment is possible using only the CLI command line, suggesting that Terraform isn’t the only option in the age of AI.
That said, Terraform offers high, reliable reproducibility, whereas AI-driven deployment doesn’t always produce the same result each time — something to keep in mind.
Bob’s documentation capabilities were strong, automatically generating everything from requirements to detailed design documents, operating instructions, and even sound-effect assignments.
Demo: Launching the Multiplayer Game
The multiplayer game built this time (Node.js + JavaScript) was deployed on IBM Cloud (Code Engine + Object Storage) using the free tier.
Attendees accessed the player screen and played a team match (Team A: 296 points vs. Team B: 287 points, with Team A winning).
Game scores and the number of participants are planned to be recorded as custom metrics in the observability tool (IBM Instana).
Presentation 2: Using BobIDE to Preserve Knowledge and Continue Development Across Sessions (Tanaka-san)
Introduction
Seigo Tanaka has worked as a freelancer since 2004, doing frontend development while incorporating generative AI, IoT, and XR.
The Docs Structure: A System for Preserving Context and Knowledge
To address the problem of AI forgetting past context across sessions, Tanaka-san introduced a custom system for managing project history.
Bob is made to write a “handover note” (Docs Letter) and a “knowledge note,” which are then committed to Git and accumulated over time.
Giving a single Markdown instruction at the end of a session automates writing the handover note, committing it, and passing context to the next session.
The knowledge notes record not just development progress but also troubleshooting details.
This system is published on GitHub as part of a collection of patterns for collaborating with AI.
Cases Where Bob Coin (Token) Consumption Increases
When the discussion broadens during the early stages of prototype development, before requirements are settled.
When the AI hesitates while resuming work on a point where past decisions wavered.
When design discussions for the next phase happen at the same time as unfinished implementation work.
When the AI’s understanding of the situation drifts, leading to frequent course-correction discussions with the user.
Tips for Reducing Bob Coin Consumption
Rather than having the AI search an entire folder of history notes, a human should point it directly to a specific file based on memory (“look at this file”).
Specify the implementation location and grep keywords before starting implementation.
Hand over the implementation plan directly from the human side as well (this is somewhat micromanagement-heavy, but effective).
Have humans handle tasks they can do themselves, such as installing libraries or running commands.
Reduce how much the AI has to think by only having it handle the next step.
Security Management System
To address the risk of AI committing sensitive information (such as passwords) to Git, the following tools are used together:
secretlint: automatically checks for sensitive information
gitleaks: a second automatic check for sensitive information
pre-commit: automatically runs checks at commit time
Relying on instructions to the AI alone is unreliable and consumes more tokens, so it’s important to supplement this with traditional, program-based mechanisms.
The commit instructions given to Bob also spell out rules in Markdown, such as “don’t push” and “don’t include sensitive information.”
Thoughts on Skills and Mode Settings (Discussion with Kano-san)
Neither Tanaka-san nor Kano-san makes much use of Bob’s skills feature or mode settings, since it’s unclear when they actually trigger.
Both prefer collecting guardrail instructions in a Markdown file and passing them in a single shot at the right moment.
As for MCP servers, they’ve only tried Playwright (browser automation); no official IBM Cloud MCP server currently seems to exist.
Next Meeting and Upcoming Plans
Next JICUG meeting: scheduled for August 25.
Kano-san plans to continue working on observability using IBM Instana (inheriting custom metrics).
JICUG Community Introduction and Opening
JICUG is a community run by IBM Cloud users, with no participation requirements — anyone can join.
Its purpose is to let users share cloud and AI technical knowledge with each other and build connections.
May’s session covered using IBM’s AI, Bob; June covered using a different AI; and this July session covers AI-driven cloud operations along with real-world experiences using Bob.
One speaker joined remotely from Tokyo Station on a mobile device, which highlighted the flexibility of remote work.
Kano-san’s Presentation: Migrating an App to IBM Cloud Using IBM Bob
Presentation Overview, Introduction, and Recap of Previous Sessions
Kano-san works at a company where he’s responsible for building, operating, and providing services for data centers and multi-cloud/hybrid-cloud environments.
This session’s theme was using AI to migrate a multiplayer game app that had been running on a virtual server to a serverless environment on IBM Cloud (Code Engine + Object Storage).
In previous sessions, a three-tier setup — web server, app server, and DB server — was built on a Linux virtual server, along with a flash-quiz app and an observability monitoring tool.
Using AI, the infrastructure setup and app development that normally takes 8 weeks was completed in about 2 days, demonstrating a remarkable efficiency gain.
This time’s migration target was a multiplayer game made up of a Node.js backend and JavaScript frontend, deployed using only the command line.
Building on the lesson from June that Terraform has a high learning cost, the simpler CLI approach was chosen this time.
Migration Steps and Results Using IBM Bob
IBM Bob was updated to version 2.0, adding enhancements such as parallel task processing via sub-agents, the ability to give additional instructions mid-task, and GUI-based MCP server support.
The migration process started by handing the requirements to Bob and having it ask about any missing information (region, whether existing resources exist, etc.) before creating a plan.
The deployment plan Bob generated automatically included an architecture overview, phase-by-phase steps, a list of variables, cost estimates, and operational notes — earning praise for its documentation quality.
Bob detected failures on its own during the work and automatically retried with alternative approaches, though some steps — like enabling public access settings in the IBM Cloud portal — still required manual work.
After the migration was complete, all attendees accessed the game and played a team match (Team A: 296 points vs. Team B: 287 points), confirming that the game worked correctly.
Metrics such as player scores and participant counts are recorded in the observability tool (IBM Instana), which was explained as being useful for digital marketing analysis.
Kano-san noted that while Terraform remains a strong option, CLI works well enough in the age of AI, and mentioned plans to explore using MCP servers and integrating with Instana further.
Seigo Tanaka’s Presentation: A System for Preserving Knowledge and Continuing Development with IBM BobIDE
Addressing Forgetting Across Sessions: The Docs Structure Context-Management System
Seigo Tanaka is an IBM Champion and, under the business name One Foot Seabus, has worked as a freelancer since 2004 in frontend development, generative AI, IoT, and XR.
Because IBM Bob has a token limit (currently around 1MB at most) and forgets past context across sessions, Tanaka-san introduced a “context-management system” (Docs Structure) that has the AI write handover notes (Docs Letter) and knowledge notes.
Simply entering a single Markdown instruction at the end of a session automatically triggers writing the handover note and knowledge note and committing them to Git.
The knowledge notes accumulate key development points and troubleshooting details, such as introducing Bootstrap, implementing the card layout, and investigating spikes in Bob coin usage.
This system is published on GitHub as “Docs Structure,” one of the patterns in a collection for collaborating with AI, complete with a one-shot installer.
Having this history means a new session can start with strong context simply by saying “proceed based on this material,” greatly reducing the need for humans to explain past context verbally.
Analyzing Bob Coin Consumption Patterns, Token-Saving Tips, and Security Measures
Cases where Bob coin consumption increases include: discussions broadening during the early stages of prototype development, wavering direction due to unclear history, moving straight to a separate task right after finishing an implementation part, and frequent course-correction discussions with the AI.
To reduce coin consumption, it helps for humans to give clearly focused instructions and point directly to specific material (“look at this”) rather than having the AI search an entire folder.
Since IBM Bob automatically selects the underlying model (such as Claude or Granite) and this is hard to control, the conclusion was that refining clear instructions matters more for saving coins than trying to control the model.
For security, secretlint and gitleaks are both used together, with a pre-commit hook automatically checking for sensitive information before each commit.
Leaving all security checks to the AI doesn’t produce consistent behavior each time and consumes more tokens, so combining this with reliable, traditional program-based mechanisms is effective for saving tokens.
The reason for preferring one-shot Markdown instructions over skills is that skills trigger at unpredictable times and can impose unexpected constraints, whereas Markdown offers better visibility and control.
Q&A and Discussion on Bob IDE Features
Kano-san asked about Bob’s settings screen (modes, MCP, skills), and Tanaka-san replied that he mainly uses one-shot Markdown instructions rather than skills.
It was shared that IBM Bob’s plan mode tends to move ahead on its own, saying things like “the plan is ready, so I’ll start developing,” so it’s effective to explicitly stop it with instructions like “write it in a note and report back.”
Regarding MCP integration, they had tried Playwright for browser automation and screen checks, but concluded that because E2E checks consume a lot of tokens, API-based or monkey testing is more reliable.
Since there’s no official MCP server for operating IBM Cloud, they introduced an approach of building a custom MCP that bundles documentation, API lists, and function lists to reduce the cost of communicating specifications.
Several unexplored features in IBM Bob’s UI — such as editor settings and start workflows — came up as things worth trying in the future.
It was discovered during screen sharing that Japanese can be selected as a language setting, suggesting a possible way to address the AI’s tendency to eagerly start responding in English.
Closing and Confirming the Next Date
The session wrapped up with a summary of Kano-san’s AI-driven app migration to a serverless environment and Tanaka-san’s approach to managing Bob’s knowledge and security.
Both speakers agreed on a shared message: managing security and accumulating project history are key to using IBM Bob with confidence over the long term.
The next meeting was confirmed for August 25, with an emphasis on locking in the date early so attendees can plan ahead.
Tanaka-san will continue to handle creating the event’s Connpass page.
Tanaka-san spoke while traveling from Nagoya to Tokyo, having quickly booked a workspace along the way — a reminder of how flexible remote participation can be.
The session closed with thanks to all attendees, and a shared commitment to continue sharing use cases for IBM Bob and cloud technology going forward.