In Agent at work, I described my first experiment with Grok Bot: a helper that cleaned thousands of duplicate photos from my Amazon Photos library without me writing a single line of code. I ended by asking whether that was really “programming.” My answer was that it was closer to directing.
This time I wanted a tougher test. Could the same kind of bot help with real code, in an app I had already written?
The app
As a learning project, I built a small Android phone app. You take a picture of the handwritten price label on an item in an antiques store. The app uses Grok, xAI’s artificial intelligence, to read the price, the item code and the vendor, then adds the taxes and prints an invoice. It worked, but it was rough around the edges. A perfect patient for the experiment.
Creating the bot: simple and fast
I described what I wanted in one sentence: help me with the Antiques Accounting project on my computer. A few minutes later, AntiquesAccounting Bot was ready.
There was one hiccup, and I’ll be honest about it. At first the bot couldn’t “see” my PC. The Grok Bot app on my computer had to connect to it, and that took a few back-and-forth messages before it suddenly worked. After that, it was smooth sailing. Patience is your ally.
Reading and understanding my code
My first request was simple: “review the project.” Within minutes the bot explained my own app back to me in plain English. It told me what each part did, where the taxes were calculated, and how the invoice was built. It also noted, politely, that almost everything was crammed into one file.
Then it asked good questions, the kind a thoughtful consultant would ask. Will this run on one phone or many? Do you need a history of sales? Which of two conflicting app names is the right one?
Suggestions that mattered
The bot came back with a short, prioritized list. Some items were real risks: if Grok answered in a slightly unexpected way, the app crashed; if the phone closed the app in the middle of a sale, everything was lost; three fake “sample” items could end up on a real customer’s invoice. Others were housekeeping, like leftover code that made the app bigger than it needed to be.
What impressed me most was the design thinking. When I mentioned the store has many vendors, it suggested one line per item in the export file so sales can be split by vendor. When I said “this data is gold,” it designed a safe approach: exporting never deletes anything, cleanup is a separate step that asks for confirmation, and a backup copy is saved first.
The speed of change
I set one simple rule: one focused change at a time, I test it on my phone, and only when I say “commit and push” does the bot save it to my online code library, GitHub.
The bot respected that rule every single time. In about a day, we completed seven changes:
- The app now reads labels reliably, even photos taken upside down. That one surprised me!
- A sale in progress survives the app being closed.
- Every sale is saved, and can be exported to a spreadsheet by date.
- Errors now show plain messages like “No internet connection” instead of gibberish, and there’s a Cancel button.
- The app shrank by a third. Faster to load.
- The project’s instructions were rewritten to match.
At one point the app crashed the moment it started. The bot read the crash report straight from my phone, found that the cause was a known bug in Microsoft’s tools rather than in my code, cleaned up, and had it running again within minutes. I would have spent an afternoon on that.
A second assistant in the room
Here is the part I find most interesting. While the bot worked, I also had Claude, an AI assistant built into Visual Studio through GitHub Copilot, open on my PC. I used it for hands-on adjustments, like finding the right versions of the database components the app needed, and some tidying of the code.
The two never got in each other’s way. Before each new change, the bot re-read the files, noticed what Claude and I had changed, and kept it.
Three assistants, one team
Looking back, everyone had a clear role:
- The bot read, reviewed, designed, made the changes, checked them, and saved them.
- Visual Studio and Claude handled the fine-tuning right where I write code.
- I supplied the context (how the store works, what matters), tested on the real phone, and made every decision.
My code library, GitHub, acted as the shared notebook that kept everyone on the same page.
So, will the store use it?
Probably not, and that’s fine. The store is happy with its paper invoice book, works on thin margins, and deals with vendors for whom paper is king. And at 84, I’m not keen on being on call seven days a week. The goal was learning, and I learned a lot. Using Grok to read handwritten labels was a real breakthrough.
What this means for you
In my first post I said the skill is shifting from knowing the syntax to knowing how to state the outcome clearly. This experiment convinced me that holds even for real software. I didn’t need to know every detail of the code. I needed to know what I wanted, test the result, and say yes or no.
If you have an idea for a small app, or one gathering dust in a drawer, this is a great time to dust it off. You don’t need to be a programmer to direct one.
Good botting!