This article was originally published on e-shikumi-labo.
Hello, I'm Shin from e-Shikumi-Labo. This is the final installment (Part 4) of "Systematized Thinking," where we use AI to build our own tools and independently maintain them.
So far, we have discussed creating a prototype that automatically saves Gemini chat logs, converting them to Markdown for Obsidian integration, and elevating it to a safe, fully automated system.
In this final installment, we will cover the "countermeasures for downtime due to screen specification changes," an unavoidable issue when operating tools that handle web data, and the core of the "self-reliance" humans should possess in the AI era.
During development, there was a time when I thought, "I also want to record the exact date and time (timestamp) when the chat was sent."
However, no matter how much I analyzed Gemini's screen structure, the exact timestamp of each utterance did not exist in the HTML.
The fundamental rule of web data extraction is: "You cannot extract data that does not exist on the browser screen."
As long as you are extracting data from the screen (DOM) rather than via an API, forcing the extraction of something that isn't there will require complex guesswork processes and will instead become a cause of trouble.
Understanding this "technical limit," gracefully giving up on what cannot be done, and judging to maintain simplicity is also an important element of tool building.
As long as you deal with tools that extract data from other people's websites, the time will inevitably come when the tool suddenly stops working one day due to design changes or updates on Google's side.
"It was working fine until yesterday, but suddenly it stopped saving."
This is not a defect in the tool, but an unavoidable "fate" as long as you depend on someone else's platform.
The important thing is not to seek an "absolutely unbreakable, perfect tool." It is to accept the premise that it will break, grasp "where and how to fix it when it breaks," and create a state where you can quickly restore it yourself.
In the "Chat Saver for Gemini" created this time, the process of reading data from the screen (DOM parsing) is separated into an independent file called parser.js
.
By separating the communication processing (content.js
) and the parsing processing (parser.js
) like this, even if Gemini's screen design changes, you only need to modify designated places (like CSS selectors) inside parser.js.
If it stops working due to a screen change, the tasks humans need to perform are as follows: Check the new elements with DevTools (Inspect Tool)
Open Gemini in Chrome, press the F12
key (or right-click > "Inspect"), and check and copy the new HTML structure of the prompt area and response area.
Request the AI to fix it
There is no need to rewrite the code directly yourself. Pass the copied latest HTML elements and the current parser.js
you have to the AI and instruct it to make corrections.
Prompt Example:"The
parser.js
stopped working due to a Gemini UI update. I have attached the currentparser.js
code, along with the latest HTML elements for the prompt area and response area. Based on this information, please modify the selector parts."
Even if you don't decipher the code yourself, simply presenting the parts that changed (input information) will prompt the AI to spit out the corrected code in seconds.
Whether you want to inspect the source code to build your own maintainable extensions or simply want a ready-to-use tool for your daily workflow, both editions are available:
MutationObserver
detection and dual export to Google Drive (.md) and Google Sheets.What I wanted to convey throughout these four parts was not just how to build a tool.
There is no need to memorize JavaScript syntax or detailed coding methods.
What humans really need to understand is the map of the overall system structure—"Input (extract from screen)" -> "Process (filter duplicates)" -> "Output (send to GAS)"—and a perspective of consideration for the data extraction source.
As long as this structural map is in your head, you can notice dangerous code produced by AI and order corrections, and even if the screen changes, you can give precise instructions to continue safely controlling the tool.
From being on the side used by tools, to being on the side that operates systems while commanding AI. I hope you all will also learn the right way to interact with AI and acquire the "self-reliance" to build and maintain safe systems tailored to yourselves.