I don’t have a problem using ADB via the command line every now and again. But between remembering where I put the executable, opening a terminal window, connecting a device, and pasting in the APK file path, it’s a bit of a chore. Booting up a small app on my PC to handle much of the legwork would be much faster.
Yes, there are already options on the market, such as ADB AppControl, EasyADB, or QuickADB. However, I wanted to build something myself that specifically focuses on the APK installation workflow — wireless debugging pairing, file/directory browsing, and bundle unpacking — rather than a full ADB control suite.
Have you ever use Google’s ADB tool?
665 votes
I use it fairly often
44%
I’ve used it one or twice
37%
Never used it
11%
I have no idea what ADB is
7%
While I’m a moderately capable programmer, between work and two kids, I don’t have the time to write an app entirely from scratch. So I thought I’d give AI-assisted “vibe coding” a try. This had the added benefit of letting me try out a new programming language I wasn’t familiar with: Go.
Why Go? It’s a simple language that’s a perfect fit for a compact project like this (no need for Rust), yet it easily compiles into a small, cross-platform executable (sorry, Python). Plus, I wanted to build a cool-looking terminal app using the beautiful Bubble Tea TUI framework that I’d recently come across. With the design in mind, I set off to find an AI agent to help me.
The trials and tribulations of vibe coding
Robert Triggs / Android Authority
I’ve dabbled in AI tools enough to know that simply asking one to build an application for you is a gamble. Expensive models from Anthropic and OpenAI can one-shot simple tasks, but you often end up in an exhausting back-and-forth to resolve bugs when you let an agent loose on a complex project. To interact with ADB and build a terminal-based UI, I decided I wanted a more hands-on approach.
I wasn’t about to spend hundreds of dollars on Opus 4.6 for this little project. Even with careful planning, there’s always a risk that models get stuck in an expensive build loop or hit an inescapable problem. Instead of asking Claude or Codex to handle the task themselves, I paired my usual IDE with OpenCode and its very affordable $10 Go subscription. That gave me access to MiniMax M2.7 and the very impressive GLM 5 to use alongside my slower human brain and keyboard-worn fingers.
I don’t trust AI to build from scratch, but it’s a major timesaver to work alongside.
I laid out the bare bones of the structure myself—folders, a few placeholder functions, a .gitignore, and so on—and wrote a quick AGENTS.md to outline the project’s requirements, goals, and coding specifics. Then, rather than asking AI to finish the whole thing, I moved slowly through the phases I knew I’d need: planning, building, reviewing, and tweaking each step along the way. I highly recommend using version control, like Git, so you can undo major AI errors and climb back out of inevitable rabbit holes.
First, I got a basic ADB wrapper working in Go, allowing me to run commands like adb devices to find connected phones and then using adb install to push APKs to them. Next, I expanded the working commands into a basic terminal interface to step through the process. That was pretty simple, but not the most user-friendly experience.
Finally — and definitely the most arduous part of the back-and-forth — was setting up the UI flow. It didn’t help that I was learning a new language and framework at the same time, but by instructing the AI agent to expose theming through a configuration file, I was able to make manual tweaks myself. That saved time (and credits) by avoiding the need to burn resources on every small detail.
Does my app actually work?
Robert Triggs / Android Authority
In the end, the combination of human planning, AI building, and tag-team tweaking produced a solid little app in just three days of off-duty work. I certainly wouldn’t have been able to write the ~3,000 lines of code by myself in that time. Not bad at all for $10, and I have plenty of credits left for another idea.
It’s a compact 7MB executable — no install required. It can automatically download ADB from Google if you don’t already have it, or use an existing PATH installation. The app launches ADB when needed and shuts it down on exit. You can pair with debuggable Android devices over USB or Wi-Fi, browse files using a built-in file explorer, and install APKs directly. It also supports unpacking and installing app bundles, including APKM, XAPK, and APKS files.
The good news is that I got a working app, and it’s genuinely useful. If there’s one drawback, it’s that I didn’t learn as much Go as I’d initially hoped. By asking AI to solve problems for me, I missed out on deeply learning the language’s syntax and patterns. I’ve picked up some understanding from reviewing the code and following the logic, but without doing much of the problem-solving myself, I still wouldn’t call myself competent in Go.
And that’s the real risk with vibe coding: not fully understanding how the code works. I spotted a couple of harmless bugs and even a zip slip vulnerability while reviewing AI-generated changes, but I can only imagine the risks when building something involving encryption, API keys, or sensitive credentials. My advice to anyone trying vibe coding is to put in the effort to plan and understand not just how your app should work, but also which tools you need, how to manage the project, and what commonly goes wrong. That way, you’re better positioned to verify AI output when it inevitably misses the mark.
If you want to give my app a try, you can find releases and the source code on the Tiny APK Installer GitHub repo. I haven’t had a chance to test the Mac or Linux builds yet, so I’m trusting that Go compiled everything correctly. If you spot any bugs, feel free to open an issue — and maybe curse AI for making it this easy to build (and break) things.
Don’t want to miss the best from Android Authority?
Thank you for being part of our community. Read our Comment Policy before posting.
