I recently had to consolidate several weeks' worth of fragmented build notes, wiring diagrams, configuration snippets, and troubleshooting discoveries into a single coherent document for our Maximo Visual Inspection (MVI) Electrical Breaker Status Demo Rig — a portable, self-contained conference demonstration platform we built at Interloc Solutions.
The documentation existed as two Word documents, multiple text files, and a collection of photos taken during the build — spread across a GitLab repository with no particular structure. I knew what needed to be done but dreaded the hours it would take. So I decided to hand the job to Bob, IBM's AI coding assistant.
(And yes — if you're wondering about the name — I do think of it as a quiet nod to For All Mankind on Apple TV+. Whether that's intentional or not, I appreciate the company.)
The Ask
Me
Bob, are you ok reading documentation in Microsoft Word format, and reorganizing it? I have several documents for a relatively complex Maximo Visual Inspection demo rig build and would like to generate a consolidated document retaining all the build steps for the physical part and the software part as well so nothing is left out of the documentation and if the build is reattempted by another person it can be repeated with minimal effort (or at least without duplicating the effort I already spent figuring out many things). All this documentation is in a folder and I have at least TWO word documents, text files, images, etc. While I can go over it and start elaborating a single consolidated document, I'm expecting I can save significant time to offload that to you, if you are able. Please let me know. Thanks!
Bob
Yes, I can absolutely help with that! I can read Word documents (.docx), text files, images, and other file types, then consolidate everything into a well-structured single document.
Here's what I can do for you:
What I Asked For
I specified two deliverables:
The source material included two Word docs, text files with Raspberry Pi setup steps and network credentials, JSON payload examples, and a Node-RED workflow with ~45 nodes across two tabs.
The Process — Live Notes
Several tool-use approval prompts appeared as Bob worked. I approved all of them within a few seconds to keep the timing realistic.
Started at 11:57 AM.
12:08 PM — README.md generated. It looked very good, IMHO.
At some point it wrote "Writing like my life depends on it…" — that was funny.
12:24 PM — Still processing. At this point I was a little worried about token consumption. The counter showed ~70k tokens.
12:36 PM — Finished. Total: ~99.4k tokens for the full run.
What Was Delivered
1. Word Document — Interloc-MVI-Breaker-Demo-Consolidated-Guide-v2.0.docx (~28 MB)
A fully structured 11-section document with embedded images, tables, and code blocks:
|
Section |
Content |
|
Cover page |
Title, version, live dashboard screenshot |
|
1. Purpose & Scope |
What the demo proves, offline design rationale, superseded guidance explicitly called out |
|
2. Architecture |
System layer table, end-to-end MQTT flow, confirmed identifiers |
|
3. Operating Procedure |
Startup checklist, trigger methods, button panel reference, shutdown sequence |
|
4. MQTT Interface |
Topic contract, trigger payload format, result fields, Base64 capture commands |
|
5. Dashboard Behavior |
Area descriptions, state logic table, watchdog behavior, flow import notes |
|
6. MVI Mobile Config |
Full settings table, Auto-Capture vs. visual trigger, image quality tradeoffs, reflection handling |
|
7. Physical Rig & Wiring |
Bill of materials, acrylic fabrication, deck layout, all 6 diagrams + 4 build photos, GPIO/LED mapping |
|
8. Raspberry Pi & Node-RED |
Network reference, Mosquitto config, full Node-RED install (wizard answers included), kiosk setup, kernel LED, sudo permissions |
|
9. Troubleshooting |
9-row symptom/cause/fix table, Auto-Capture root-cause analysis, GPU patch, OOM resolution |
|
10. Event Runbook |
Pre-event acceptance checklist, daily startup, recovery kit |
|
11. Extensions |
Thermal camera concept, enterprise integrations, full source artifact index |
2. README.md (~13 KB)
A complete project README replacing the GitLab default boilerplate — covering what the rig is, repository structure, quick-start checklists, network reference, MQTT topics, GPIO mapping, daily operation, troubleshooting table, and future extension ideas.
My Review — Less Than 25 Changes on a 20-Page Document
I went through the document and made fewer than 25 minor changes in total — roughly 1–2 per page on a 20-page document. That's an exceptionally low editorial overhead for a first pass on consolidated technical documentation assembled from messy, fragmented sources.
Changes I made included:
Round Two — The "Error" Consistency Fix
After my manual edits I submitted a follow-up prompt asking Bob to find and fix any remaining instances of the old "Error / ACK" label for the Red button — making sure my other edits (the expanded BOM, updated screenshot, formatting) were preserved.
Bob analyzed the Word document's raw XML, identified exactly two remaining inconsistencies, and applied surgical patches directly to the XML without disturbing anything else:
− Section 7 GPIO table: Red — Error / ACK
+ Section 7 GPIO table: Red — Fail / ACK
− Section 10 Runbook: confirm Red ACK, Yellow CLR, and shutdown interlock behavior
+ Section 10 Runbook: confirm Fail / ACK (Red), Pass / CLR (Yellow), and shutdown interlock behavior
It also correctly left three other instances of the word "error" alone — an MQTT topic name (ibmvi/error/…), a descriptive sentence about dashboard false positives, and GPU/container training error codes. Context-awareness, not just find-and-replace.
Total time for the follow-up: approximately 4 minutes.
The Numbers
~39 min
Initial doc generation
(11:57 AM → 12:36 PM)
~4 min
Follow-up consistency
patch run
99.4k
Tokens — initial run
130.5k
Total tokens across
both interactions
~$8.77
Total estimated cost
("Bobcoins")
< 25
Manual edits on a
20-page document
Final Thoughts
Would I do it again?
Absolutely. The document came back internally consistent in a way my original notes never were — outdated references removed, superseded steps explicitly called out, tables properly cross-referenced. The kind of coherence that usually requires a dedicated technical writer doing a careful pass.
For roughly $5 and about 40 minutes of (mostly unattended) compute time, I got a 20-page consolidated build guide that I only needed to touch ~25 times. For a document type that I'd estimate would take 4–6 hours of manual effort to produce from scratch, that's a very strong result.
The follow-up patch interaction — 4 minutes, ~$3.77, zero broken edits — reinforced the point. It didn't just blindly find-and-replace; it understood which instances of "error" were button labels versus MQTT topic names versus technical error codes, and treated them accordingly.
The one thing I'd improve for next time: start with a slightly more structured initial prompt that includes the full BOM explicitly rather than relying on Bob to infer it from scattered source material. That would have saved my one real content addition.
Otherwise — highly recommended for anyone sitting on a pile of fragmented technical notes who needs them turned into something a colleague can actually follow.
The demo rig is a portable conference platform used by Interloc Solutions to demonstrate IBM Maximo Visual Inspection Mobile performing real-time AI object detection on physical electrical circuit breakers — entirely offline, using a Raspberry Pi, local MQTT broker, Node-RED dashboard, and on-device CoreML inference on an iPhone SE.
Interloc Solutions · Technical Blog · August 2026
Made with IBM Bob