TrenchOps 🐎 
4 Hours of Battery, 6 Months of Patience, 10 Minutes of Work
The bottleneck was never the technology. It was my imagination.
The slow leak
For roughly half a year my Android phone had the battery life of a mayfly. Two charges a day. Not broken enough to fix, not good enough to forget. That particular purgatory where a problem is expensive in aggregate and cheap in any single moment, so it never wins the fight for your attention. You know the state. Everyone knows the state. It is where most technical debt lives, in companies and in pockets. So it sat there, not broken enough to justify a new phone, too annoying to ignore. Charge twice a day instead of once. "Maybe it dies properly soon and I buy a new one anyway." That is not a plan. That is a truce, and it lasted about five months.
I had seen this pattern before. The usual suspect on Android is the media server, the background service that generates thumbnails and chews through your photo library. Classic failure mode: one corrupt file with broken metadata, the service retries forever and happily converts your battery into warmth. The traditional cure was moving most photos off the device, which at least doubled as a forced backup day. Mildly humiliating, but effective.
This time, nothing worked. Deleted photos I did not need. Rebooted. Restricted background access, which Android grants system apps with the enthusiasm of a German landlord approving a wall-mounted TV. Forced aggressive battery optimization. Updates. Nothing.
Eventually the annoyance crossed the threshold and I asked an AI assistant for advice. It recited the same checklist I'd already exhausted. Of course it did - that's the internet's collective wisdom, and I had already tried the internet's collective wisdom.
Then I had the thought that actually mattered: "what if I just plug the phone into my Linux machine, hand the AI control of ADB - the Android Debug Bridge, the command line channel between PC and phone - and let it investigate on its own?"
Ten minutes later it came back with a diagnosis I would never have reached by clicking around in Settings. My gallery app was ancient. Not merely outdated - the project had been acquired, turned commercial, and the branch I was running had been quietly abandoned. And abandoned code keeps its bugs forever: the thing was stuck in a permanent scan loop, re-indexing the SD card over and over. The device was not dying. It was being nagged to death.
Recommendation: uninstall it, install the maintained open source fork. For good measure, it purged the old thumbnail database to rule out corruption there too. Delete, replace, delete. Nothing new was built. Nothing was tuned.
Reboot. Charge. The battery manager now estimates around 19 hours. Before: about 4.
Six months of annoyance. Ten minutes of actual work. The rest was me not asking.
The wrong question
I spend a lot of time learning about AI, and almost none of it is about frameworks, syntax, or which protocol connects which tool to which model. That layer changes every quarter and mostly takes care of itself.
The thing I keep learning is harder: "which problems am I wrongly assuming are out of scope?"
Because I do that constantly. I look at a task and my head says "that is not something a language model knows anything about" and the task never gets tried. In more cases than not, my head is wrong. Not always - I recently tried to get AI to edit WordPress pages built with Elementor, and the result was the digital equivalent of letting a very confident intern rearrange your living room by phone. Fine. It tried, I stopped early, cost of experiment: twenty minutes. No harm done. (That being said, during that attempt the AI discover a misconfigured firewall rule on the server which the hosting support happily resolved so it was not for nothing.)
That asymmetry is the whole point. Failed attempt: a coffee break. Successful attempt: half a year of daily friction deleted, or a lawsuit won. I used AI on a legal case once and won it. I have read about people plugging their car into the diagnostics port and letting a model read the fault codes. My favorite story is the woman who feeds every contract and every bill above twenty dollars into a chatbot to check whether the price is fair, whether a cheaper option exists, and whether she has a claim. She is apparently making good money doing it.
None of these people are technically sophisticated (at least not in the AI sense). They are just missing the fence I kept building in my own head.
Chesterton's fence - the principle that you should not tear down a fence before you know why someone put it there - is excellent advice for rules other people built. It is terrible advice for the fences you built yourself out of assumptions you never tested. Those you should kick over routinely, because nobody put them there on purpose. They are leftovers from a version of the technology that expired eighteen months ago.
The safety harness, because I care about your data
Fire away, yes. Recklessly, no.
👉 Redact before you upload. Names, account numbers, credentials, medical details. Assume anything you paste leaves your control forever.
👉 Backup first, always. Especially before letting anything automated near family photos. Read-only investigation is a different risk class than "go ahead and fix it."
👉 Supervise. My ADB session worked because I read every command before it ran. The model suggested, I approved. That distinction is the entire difference between a diagnosis and an incident.
👉 Judge by results, not by your prior. Give the experiment a fixed time budget, then rule on the output. If it fails, you lost a coffee break.
👉 Keep a personal list of "things I assumed AI cannot do." Revisit it quarterly. It ages badly, which is exactly the signal you want.
The scarce resource is no longer knowing how the stack works. It is having the nerve to point the thing at a problem nobody told you it was for.
👇 What is the one problem you have been quietly tolerating for months because you assumed nothing could help? Try it this week and tell me what happened.
0 comment(s)
No comments yet. Be the first to comment.
Leave a comment