The following is based on an AI-generated meeting transcript from Rimo.
Discussion Points
In AI-driven development, clarifying requirements, basic design, screen layout, and technology choices before coding reduces rework and token consumption.
Gaps in the division of responsibilities between frontend and backend, or in the communication spec between them, lead to heavy token consumption during mid-implementation checks and fixes, so the spec connecting the two needs to be defined up front.
Specifying not only what to leave to AI but also “technologies and tools not to use” helps curb unnecessary suggestions and implementations.
Participants shared the view that a spec document functions much like programming in natural language.
Across the three talks, it was confirmed that instead of leaving everything to AI, developers need to translate their own vision, constraints, and existing knowledge into the spec document.
Opening & Administrative Notes
The Zoom URL announcement email hadn’t been sent in advance, so it was sent to participants right before the start.
There were 11 registrations, with last-minute cancellations and additional sign-ups bringing the number up by about 3 just before the start.
This time, the Connpass survey feature wasn’t linked up with PlayOn.
The IBM Cloud User Group was introduced as a community run not only by IBM employees but by any users interested in IBM Cloud or IBM’s AI who want to participate or help organize it.
Last time, in August, the group held an AI hackathon where about 36 participants split into 6 teams and built AI-powered apps on the spot.
LT #1: AI-Driven Development of a Different-Themed App Each Month, “This Month: Kaizen” (Ichiro Kano)
Purpose and App Overview
This month’s theme was “Kaizen” (improvement).
Kano-san built “QC Playbook,” a digital whiteboard app that supports small-group activities and QC activities on the manufacturing floor.
The goal is to make it easier for frontline staff to voice opinions, organize them, and turn them into improvement proposals.
In the app, users can enter opinions on sticky notes, move the notes around, share comments, and link related notes with connectors.
The whiteboard can switch between steps such as understanding the current situation, analyzing it, and planning improvements, with SWOT analysis and fishbone diagrams in mind as use cases.
Development Process
The development flow went in this order: requirements definition, basic design by AI, coding, then inspection and fixes.
Before coding, Kano-san inserted several rounds where, if there were any gaps or undecided points in the design, AI would ask questions about them.
GUI design, infrastructure configuration, and the placement of sound files were organized in advance, converted from PowerPoint to PDF, and fed into IBM Bob.
AI identified undecided items and settled them one question at a time, covering things like the real-time sync method, backend language, and graphics library.
Even after the basic design was done, AI was asked to confirm any additional items that needed deciding before coding began.
Development Results and Token Consumption
Writing the spec took about 2 days, while the first round of coding was done in about 8 minutes.
In the talk, Kano-san explained that requirements definition and basic design consumed about 5 Bob coins, and the first round of coding consumed about 4 Bob coins.
Once fixes after completion were repeated, token consumption rose sharply, since each fix involved reading past code, drafting a fix, applying it, and checking it.
Kano-san noted that showing screen colors and shapes concretely in a diagram can sometimes reduce the token cost of fix instructions.
The takeaway shared was that investing more in upfront design helps curb both the number of post-coding fixes and token consumption.
Live Demo
Participants accessed the app from their browsers and tried renaming the project, entering comments, creating sticky notes, moving sticky notes, and linking notes with connectors.
They confirmed that comments and sticky notes could be shared in real time.
Sound effects were implemented, and Kano-san explained that the spec had specified in detail where the sound files were placed, their file names, and the scenes where they play.
Canvas content can be downloaded in JSON format and reloaded next time to reproduce the same state.
A planned feature was introduced where, once logged in, users could save multiple environments on the server side.
LT #2: Musings on Running IBM Bob Alongside a Web 3D + IoT Setup on IBM Cloud Code Engine (Seigo Tanaka)
System Architecture
Seigo Tanaka introduced a case where he developed a Web 3D and IoT combined system on IBM Cloud Code Engine together with IBM Bob.
The main stack was as follows:
Backend: Hono (Node.js)
Frontend: Vue 3, Bootstrap 5
3D rendering: BabylonJS
IoT connectivity: MQTT over WebSocket
Devices: M5Stack Atom S3 and tape LEDs
It’s a prototype combining the frontend, 3D rendering, IoT communication, and deployment to Code Engine.
Live Demo
Tanaka-san rotated a 3D object in the browser, and operated stop-rotation and angle-reset controls.
Button presses in the browser were received by the server on Code Engine and sent to the IoT device via MQTT.
He demonstrated turning an LED connected to the M5Stack Atom S3 on and off.
LED control works by sending RGB values as JSON, treating red as “on” and black as “off.”
A design was introduced where the device’s MAC address is used to make the MQTT topic unique.
MQTT Communication and Device Setup
The device connects to an external MQTT broker and subscribes to the relevant topic to receive messages.
Rather than polling over HTTP at intervals, the setup keeps a connection to the MQTT broker open to receive messages.
On the device side, communication is handled inside the Arduino loop, responding in roughly under a second.
A participant added that similar IoT control is also possible on a Raspberry Pi running Linux.
Spec Design and Knowledge Management
Tanaka-san had AI keep notes on the development process, so design intent and the causes of past issues could be looked up later.
Accumulating this history made it easier for AI to discuss things with past design and bug information in mind.
To avoid leaking secrets into the public GitHub repository, he ran secret scanning with Gitleaks.
Detailed specs were written separately for the frontend, 3D rendering, IoT, and Code Engine deployment.
Technology choices, library versions, 3D object size, camera angle, UI components, MQTT topics, environment variables, and the Dockerfile were all specified up front.
Frontend and backend responsibilities were kept separate so the scope wouldn’t expand too much.
He had trouble setting environment variables on Windows, and said dealing with that consumed about 5 Bob coins.
The initial phase, including the spec and history management, consumed about 20 Bob coins, and the whole project, including trial and error and UI tweaks, consumed around 40 Bob coins overall.
The takeaway was that by translating the developer’s own vision and knowledge into detailed specs, even an implementation combining multiple technologies like Web 3D and IoT could go relatively smoothly.
LT #3: Building a Self-Hosted, Multi-User NotebookLM-Style Local RAG Web App for Local Governments and Educational Institutions, Built on Granite 4.2 (Kohei Nishikawa)
App Overview
Nishikawa-san is developing a self-hosted, multi-user RAG web app in the style of NotebookLM, aimed at local governments and educational institutions.
Because authentication, multi-user support, and storing specs for future maintenance were all needed, he built it as a dedicated app.
It’s currently in alpha, and starting the week after this meeting, local governments will try it out and feed their feedback back into development.
The basic policy is to run it in a local environment, aiming for a setup that doesn’t depend on external generative AI services.
Technical Stack
Framework: Next.js, TypeScript, React
Supported documents: PDF, Markdown, Word files
LLM: Granite 4.2 3B
RAG methods: standard RAG, HyDE RAG
Runtime environment: local environment
Granite 4.2 3B was set as the default model, with the Granite 4.2 series recommended overall.
He explained that he’s using a small language model that runs even on a PC with 32GB of memory, with the 8B model also mentioned as a candidate.
Development Process
He first used ChatGPT and Claude to write the spec, rewriting it about 7 times total, from version 1.0 up to 1.6.
He fed the spec into IBM Bob, had it create a plan file, and then moved on to implementation.
Implementation was split into multiple phases and checked one step at a time, which helped avoid overlooked libraries and unnecessary token consumption.
Keeping a change history for the spec and implementation prompts made it easier to trace the cause when errors occurred.
Key Features and Demo
Login and multi-user support
A guide display for users
Uploading PDF, Markdown, and Word files
Automatic chunk detection for documents, with manual editing
Switching between standard RAG and HyDE RAG
Checking the hypothetical search text generated by HyDE RAG
Showing the citation source, page number, and similarity score for search results
Operation logs for things like logging in/out and creating notebooks
Visualizing system and generation settings, such as CSRF protection and temperature, in the admin screen
A design choice to let system-side settings be checked on screen rather than in a terminal
Q&A and Technical Discussion
MQTT and IoT Devices
The M5Stack Atom S3 receives messages in real time by staying connected to the MQTT broker and subscribing to it.
It was explained that this method keeps an MQTT connection open, rather than polling at intervals the way HTTP does.
A comment noted that a Raspberry Pi could achieve a similar setup, as long as the necessary software and programs are in place on Linux.
Sound Effects and UI Implementation
The sound effects in QC Playbook were implemented by specifying the sound file locations, file names, and the scenes where they play in the spec.
The instructions included onomatopoeia like “pilon” (a short chime) and “kirarin” (a sparkly shimmer sound), leaving the choice of the actual sound library up to AI.
Participants noted that specifying the screen layout, left/right menus, use of Bootstrap and Bootstrap Icons, and icon names in advance makes it easier to get closer to the intended design.
It was confirmed that making major UI changes later increases token consumption, so it’s important to decide on the screen layout early.
Shared Lessons on AI-Driven Development
A spec document isn’t just supplementary material — it functions as a natural-language program instruction to AI.
Taking care with requirements definition and basic design improves the accuracy of the first implementation and curbs the token consumption that comes with fixes.
Gaps in the spec between backend and frontend lead to major rework when adjustments are made after implementation.
It’s important for the spec to cover not just what to hand to AI, but also the developer’s own knowledge, technical constraints, technologies not being adopted, and notes on environment variables and security.
There was shared agreement that separating what’s left to AI from the design decisions humans make lets even prototyping that combines multiple technologies proceed efficiently.
Summary
This session covered AI-driven app development through three different cases: supporting QC activities, Web 3D and IoT integration, and a local RAG for local governments and educational institutions.
All three talks showed that writing a spec in advance, putting design intent into words, and recording the development history are effective for implementation stability and for curbing token consumption.
After the talks, participants exchanged views on QC Playbook, MQTT, Granite 4.2, UI design, and how to approach AI-driven development, before the meeting wrapped up informally.